snapping_in_pcb
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
snapping_in_pcb [2018/07/07 17:29] cparker |
snapping_in_pcb [2018/07/11 21:46] cparker [Discussion] |
||
|---|---|---|---|
| Line 199: | Line 199: | ||
| =====Discussion===== | =====Discussion===== | ||
| This section is for ideas and discussion regarding things related to the snapping implementation. | This section is for ideas and discussion regarding things related to the snapping implementation. | ||
| + | |||
| ==Who Does the Snapping== | ==Who Does the Snapping== | ||
| Regarding the crosshair integration, there is a question in my mind about algorithm. Should the crosshair be responsible for the snapping? Presently the procedure is... | Regarding the crosshair integration, there is a question in my mind about algorithm. Should the crosshair be responsible for the snapping? Presently the procedure is... | ||
| Line 215: | Line 216: | ||
| One thing I'm on the fence about is if the snapping functions should get a pointer to the SnapSpecType they were called from. Presently, the functions answer the question: "is there something of this type under the cursor that can be snapped to?". To answer that question, the SnapSpecType data isn't required, and so presently it's not provided. However, if this were to become more sophisticated in the future, it might become necessary. | One thing I'm on the fence about is if the snapping functions should get a pointer to the SnapSpecType they were called from. Presently, the functions answer the question: "is there something of this type under the cursor that can be snapped to?". To answer that question, the SnapSpecType data isn't required, and so presently it's not provided. However, if this were to become more sophisticated in the future, it might become necessary. | ||
| + | ==Snapping Modifiers== | ||
| + | A very nice feature would be if the user could press a mod key to change the snapping behavior. Perhaps the cursor only snaps to grid points normally, and then starts snapping to everything else when "alt" is held. | ||
| + | |||
| + | There are several places where this kind of behavior could be implemented. The basic idea behind them all is that you would have a second ''SnapList'' that was applied to the other condition. | ||
| + | 1. In the search_snaps function. It could check in with the gui to see if the modifier is active, and then select a ''SnapList'' to search. | ||
| + | 2. The crosshair could do the same thing before it calls the search_snaps, and pass the appropriate list to the search function. | ||
| + | 3. The gui could control it, watch the modifier key and change the active SnapList when the state of the key changes. | ||
| + | 4. A plugin can actually be implemented to do this. Since plugins can access the gtk structures, a plugin could install a listener function to listen for modifier key strokes, and update the crosshair snap list accordingly. | ||
| + | |||
| + | Option 4 is the most modular, and I did write this infrastructure so that plugins could be used to modify the behavior. I think I'm going to try that method first. | ||
| + | |||
| + | How does it work? | ||
| + | The plugin is loaded and creates it's alternate ''SnapList''. It can populate it from the structures that already exist in crosshair.c, I think, by declaring them as externs. | ||
| =====TODO List===== | =====TODO List===== | ||
| - | * Configuration actions | ||
| * snap based on screen distance instead of linear distance | * snap based on screen distance instead of linear distance | ||
| * don't snap to off-screen objects | * don't snap to off-screen objects | ||
snapping_in_pcb.txt ยท Last modified: 2019/03/21 12:50 by cparker
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
