On Wed, 12 May 2004, Bryce Harrington wrote:
Sounds like a very well thought out approach for snapping. I'm looking forward to playing with it. I like the approach you took of making the new behavior a selectable option, just in case the old method is preferred.
Regarding snap points, what are your thoughts about how other ways they could be implemented? You're right that new ideas could be beneficial there.
Well, I'm still a bit unsure about it all. But I think the basic problem is that there is currently a bit a mish-mash of exactly what snaps to the grid.
For example, you draw a square with the pen tool. The nodes are snapped to the grid. Then, you scale the square. Suddenly, the bounding box of the square (which includes its line width) is snapped to the grid and so the nodes are no longer snapped. Similarly, moving the square (without my Shift-drag patch) starts snapping it to the bounding box. In contrast, if you draw the square with the rectangle tool, things behave differently.
Now I imagine that there are people would would like both behaviours (node snap and bounding box snap). But I suspect we probably want a definite switch for this, so that in one mode we snap to nodes and in the other we snap to bounding boxes.
That's the UI, anyway. The best implementation of node snap for moving might be to alter the snap points that are used for snapping; currently these are usually bounding-box related, but they could be nodes.
The scaling implementation is different again, because here you have the question of what the scale origin is. Currently, it's the bounding box. But if you're wanting nodes to stay snapped (where possible) you want the origin to be a node instead.
What do you think to an option along the lines of "snap to nodes / snap to bounding boxes" that affects these behaviours?
I'm unclear where the shift-drag "move offset is snapped to the grid" patch comes into this. It might not be required if the snap points stuff is sorted out.
Cheers
Carl