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 | ||
|
snapping_in_pcb [2018/07/08 10:06] cparker [TODO List] |
snapping_in_pcb [2019/03/21 12:50] (current) cparker [TODO List] |
||
|---|---|---|---|
| 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. | ||
| + | |||
| + | I'm currently experimenting with this in the home/cparker/mod_snapping_plugin branch. I have this code built as a plugin, but I also included it in the source tree just in case people had trouble with the plugin. | ||
| + | |||
| + | ==Snapping and Layers== | ||
| + | It's frequently the case that you only want to snap to objects on certain layers. What's the best way to implement this? | ||
| + | |||
| + | Presently, SearchObjectByLocation doesn't have a layer parameter. It simply iterates over them all with every search. So, we would have to expose some of the lower level searching functions in order to restrict layers, or add layers as a parameter to SearchObjectByLocation. That function is called in a lot of places, so, it would be a lot of calls to have to update. | ||
| + | |||
| + | How do I keep track of which layers I'm searching? Do I pass pointers? Layer numbers? | ||
| =====TODO List===== | =====TODO List===== | ||
| + | * rebase the code off of the object_list instead of using dedicated list types. | ||
| * 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 | ||
| Line 224: | Line 248: | ||
| * tests | * tests | ||
| + | =====Current Work In Progress===== | ||
| + | Based on email exchanges and testing by Richard. | ||
| + | |||
| + | The snapping code needs to know about layers. We want to be able to search for things to snap to only on certain layers, and then in a particular order. | ||
| ===== Related Pages ===== | ===== Related Pages ===== | ||
| * [[PCB Crosshair|PCB Crosshair]] | * [[PCB Crosshair|PCB Crosshair]] | ||
snapping_in_pcb.1531058788.txt.gz ยท Last modified: 2018/07/08 10:06 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
