On Wed, 12 May 2004, Carl Hetherington wrote:
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.
*Nod* My suspicion is that this behavior may make intuitive sense for illustration type drawing, where you don't want things to overlap and are using guidelines more than the grid, but becomes cumbersome when doing technical drawing.
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.
Yes, and the star tool is similarly inconsistent, but inconsistently with how rects are snapped. Erf!!
It definitely would seem to make the most sense to change the default behavior so that it works consistently, one way or the other, when initially drawing the shape and when resizing it. By default one should ideally get the same snap result regardless of whether scaling or node-editing, I think.
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.
I'm of the same mind. I also suspect someone could desire different behavior out of the grid than from the guidelines. For instance, I can easily see myself using the guidelines as a way to "override" the grid for things like absolute centering (regardless of object dimensions).
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.
*Nod* I'm definitely in favor of this for technical drawing purposes. I could certainly see that this behavior might get weird for someone if they were doing vector illustration and dealing with complex shapes that have gobs of nodes, though. Node-based snapping should definitely be an option.
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.
Note that it's also possible to scale based on the center point (via shift-drag). We'll have to think about how that should snap (bounding box or to node points), as it could desire a different approach.
What do you think to an option along the lines of "snap to nodes / snap to bounding boxes" that affects these behaviours?
*Grin* I think we're on the same wavelength.
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.
It's definitely a step in the right direction, but yeah, if we can come up with a more universal solution that provides the same effect, it might not be required. I'd say definitely put it in for now, since it's ready to go. Then if snap points takes longer to figure out than this release, we'll at least have some improvement to snapping behavior.
Bryce