Grid-related patches committed for comments
Hi,
I've committed a couple of patches to the grid behaviour, after discussion with Buila on jabber. If anyone has problems, please say so and I'll fix or back out the patch.
1. Removed feature where alt-drag provides a "slow drag" when moving objects.
2. When moving objects, alt-drag now moves them without snapping, even if the grid is enabled.
3. When moving objects with the grid enabled, the current behaviour is to snap the objects "snap points" to the grid. This patch adds an alternative behaviour on Shift-drag: moved objects are snapped such that they keep the offset from the grid that they had before the move.
4. When you paste an object it is pasted at the same offset from the grid as the original.
5. An option in Inkscape preferences to make (3) the default and the current behaviour happen on Shift-drag.
My rationale for (3), in case anyone's interested:
It's basically for doing simple line drawings. Draw a simple shape made out of straight lines, some of whose points are snapped to the grid. Now if you move this object around, the bounding box of this object will be snapped, rather than the points themselves. This means that the line position plus its width will be snapped. If you then try to draw another line which joins to the object you've just moved, the new line's points will be snapped. Hence the old object and new line will not meet up, being offset by half the line width.
It's possible that this would be better implemented by improving Inkscape's ideas of what "snap points" are, but the end result would be similar.
Thanks
Carl
On Wednesday 12 May 2004 16:33, Carl Hetherington wrote:
- When moving objects, alt-drag now moves them without snapping, even if
the grid is enabled.
This is _cool_! I have been thinkling of such a thing. So, it disables snapping to guides too? I think alt-drag should disable all types of snapping.
Artemio.
On Wed, May 12, 2004 at 02:33:26PM +0100, Carl Hetherington wrote:
- When moving objects with the grid enabled, the current behaviour is to
snap the objects "snap points" to the grid. This patch adds an alternative behaviour on Shift-drag: moved objects are snapped such that they keep the offset from the grid that they had before the move.
- When you paste an object it is pasted at the same offset from the grid
as the original.
AAAh! So cool! That's always been a major frustration for me when working in a snap-to-grid environment. Very nice!
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.
Bryce
On Wed, 12 May 2004, Carl Hetherington wrote:
Hi,
I've committed a couple of patches to the grid behaviour, after discussion with Buila on jabber. If anyone has problems, please say so and I'll fix or back out the patch.
- Removed feature where alt-drag provides a "slow drag" when moving
objects.
- When moving objects, alt-drag now moves them without snapping, even if
the grid is enabled.
- When moving objects with the grid enabled, the current behaviour is to
snap the objects "snap points" to the grid. This patch adds an alternative behaviour on Shift-drag: moved objects are snapped such that they keep the offset from the grid that they had before the move.
- When you paste an object it is pasted at the same offset from the grid
as the original.
- An option in Inkscape preferences to make (3) the default and the
current behaviour happen on Shift-drag.
My rationale for (3), in case anyone's interested:
It's basically for doing simple line drawings. Draw a simple shape made out of straight lines, some of whose points are snapped to the grid. Now if you move this object around, the bounding box of this object will be snapped, rather than the points themselves. This means that the line position plus its width will be snapped. If you then try to draw another line which joins to the object you've just moved, the new line's points will be snapped. Hence the old object and new line will not meet up, being offset by half the line width.
It's possible that this would be better implemented by improving Inkscape's ideas of what "snap points" are, but the end result would be similar.
Thanks
Carl
This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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
participants (4)
-
Artemio -
Bryce Harrington -
Carl Hetherington -
Kees Cook