Help with more grid problems
Hi,
My next grid problem is this:
1. Turn the grid on. 2. Draw a 1x1 square on this grid using the pen tool.
Note that the nodes of this square are snapped to the grid.
3. Scale this square using the handles and stop when the scale snaps near a size of 2x2.
Now that square's nodes are no longer snapped to the grid.
AFAICS this is because the scaling makes use of the sp_item_bbox_desktop(), which includes line widths. It suggests to me that the only way to solve this problem is to have a second bounding box function that considers nodal positions only. Then this could (optionally) be used for scaling.
Any thoughts? Have I missed something?
Thanks
Carl
On Wed, 12 May 2004, Carl Hetherington wrote:
Hi,
My next grid problem is this:
- Turn the grid on.
- Draw a 1x1 square on this grid using the pen tool.
Note that the nodes of this square are snapped to the grid.
- Scale this square using the handles and stop when the scale snaps near
a size of 2x2.
Now that square's nodes are no longer snapped to the grid.
AFAICS this is because the scaling makes use of the sp_item_bbox_desktop(), which includes line widths. It suggests to me that the only way to solve this problem is to have a second bounding box function that considers nodal positions only. Then this could (optionally) be used for scaling.
Any thoughts? Have I missed something?
I've always been bugged by this too. Yes you're right that it seems to be basing the snap coordinate on the bounding box rather than the snap point as you'd expect. Perhaps this was done in a desire to allow shapes to fit within the grid boundaries. For instance, I can easily see how if you're making an artistic drawing, you might want to see things snap to their "real" edges rather than to their node points. However, as you note, for technical drawing it does not work out right, since the "centerlines" are the important thing, not the line widths.
Perhaps an idea would be to provide an option in the grid/snap dialog for the following snapping behaviors:
Snap objects to their: Grid Guides outermost edges [ ] [X] node points (default) [X] [ ] center point [ ] [X] ( pivot point [ ] [ ] ) moment of inertia [ ] [ ] ( connection points [ ] [ ] )
(The last one isn't available since connection points aren't implemented, but when they are, it could be an option.)
(The pivot point currently is 'forgotten' when changing out of transform mode, but if we ever decide to store it persistently, it might be a useful snap point too.)
Moment of inertia would probably be a pain (er, 'interesting challenge') to implement but I suspect that for complicated shapes it might provide a more useful snapping point than the center of the bounding box. (Consider a lollypop or a shape with some attached dimension lines as examples.)
I think that the importance of node-point-based snapping increases in importance when we have non-square grids. I know Nathan has long been interested in adding iso, hex, etc. grid types, and the bounding-box style of snapping will just feel wrong with those kinds of grids.
Creating a bounding box from the node points rather than the outer edges may solve it, but it'd be interesting to know if it'd be possible to snap to the node points themselves. For example, wouldn't it be nice if stars could be snapped to the grid on their points?
Regarding star snapping behavior, notice that when you initially draw the star, it snaps to its center, but when you move it it snaps only to its bounding box. Erf! It probably ought to consistently do one or the other, with an option to achieve the other effect.
Also, on the topic of weird things happening when you resize stroked boxes, another technical drawing 'mis-feature' worth figuring out a good alternative solution for is how the stroke width is scaled. Normally when doing a technical drawing you will want to scale some boxes but maintain a consistent line width on everything. It would be valuable to have an option in preferences to control whether stroke width is scaled with object scaling or not.
Bryce
On Wed, 12 May 2004, Bryce Harrington wrote:
[snip]
I've always been bugged by this too. Yes you're right that it seems to be basing the snap coordinate on the bounding box rather than the snap point as you'd expect. Perhaps this was done in a desire to allow shapes to fit within the grid boundaries. For instance, I can easily see how if you're making an artistic drawing, you might want to see things snap to their "real" edges rather than to their node points. However, as you note, for technical drawing it does not work out right, since the "centerlines" are the important thing, not the line widths.
Absolutely. I think the "artistic / technical" is probably the best distinction.
Perhaps an idea would be to provide an option in the grid/snap dialog for the following snapping behaviors:
Snap objects to their: Grid Guides outermost edges [ ] [X] node points (default) [X] [ ] center point [ ] [X] ( pivot point [ ] [ ] ) moment of inertia [ ] [ ] ( connection points [ ] [ ] )
Yes. I think this is the idea I had come around to, as well.
[snip details of particular snap behaviours]
That's fine. Once the structure is in place we can add snap behaviours to our hearts' contents.
I think that the importance of node-point-based snapping increases in importance when we have non-square grids. I know Nathan has long been interested in adding iso, hex, etc. grid types, and the bounding-box style of snapping will just feel wrong with those kinds of grids.
I'm sure.
Creating a bounding box from the node points rather than the outer edges may solve it, but it'd be interesting to know if it'd be possible to snap to the node points themselves. For example, wouldn't it be nice if stars could be snapped to the grid on their points?
That's true. I think we can achieve that if we improve the code that generates a list of snap points.
Regarding star snapping behavior, notice that when you initially draw the star, it snaps to its center, but when you move it it snaps only to its bounding box. Erf! It probably ought to consistently do one or the other, with an option to achieve the other effect.
Absolutely. The inconsistency is the annoying thing, I think.
Also, on the topic of weird things happening when you resize stroked boxes, another technical drawing 'mis-feature' worth figuring out a good alternative solution for is how the stroke width is scaled. Normally when doing a technical drawing you will want to scale some boxes but maintain a consistent line width on everything. It would be valuable to have an option in preferences to control whether stroke width is scaled with object scaling or not.
Couldn't agree more. Inkscape preferences -> Transforms -> Scale stroke width
;-)
Carl
Carl Hetherington wrote:
On Wed, 12 May 2004, Bryce Harrington wrote:
[snip]
I've always been bugged by this too. Yes you're right that it seems to be basing the snap coordinate on the bounding box rather than the snap point as you'd expect. Perhaps this was done in a desire to allow shapes to fit within the grid boundaries. For instance, I can easily see how if you're making an artistic drawing, you might want to see things snap to their "real" edges rather than to their node points. However, as you note, for technical drawing it does not work out right, since the "centerlines" are the important thing, not the line widths.
Absolutely. I think the "artistic / technical" is probably the best distinction.
Perhaps an idea would be to provide an option in the grid/snap dialog for the following snapping behaviors:
Snap objects to their: Grid Guides outermost edges [ ] [X] node points (default) [X] [ ] center point [ ] [X] ( pivot point [ ] [ ] ) moment of inertia [ ] [ ] ( connection points [ ] [ ] )
Yes. I think this is the idea I had come around to, as well.
No, this is wrong. You almost always want to snap to nodes. In the rare case that someone actually wants to snap to the bounding box they can use stroke to path to convert the shape to a new set of nodes. Please, don't start making preferences for everything!
Make the snap points always the nodes, and additionally, the extreme points of the curve.
njh
[snip: making snap-to-nodes / snap-to-bbox optional]
No, this is wrong. You almost always want to snap to nodes. In the rare case that someone actually wants to snap to the bounding box they can use stroke to path to convert the shape to a new set of nodes. Please, don't start making preferences for everything!
Personally, I'd be perfectly happy with this. But as soon as someone says "I myself use bbox snapping" then I'm ok, in this case, with making it optional. I agree about keeping preferences down where possible.
Cheers
Carl
On Thu, 13 May 2004, Carl Hetherington wrote:
rare case that someone actually wants to snap to the bounding box they can use stroke to path to convert the shape to a new set of nodes. Please, don't start making preferences for everything!
Personally, I'd be perfectly happy with this. But as soon as someone says "I myself use bbox snapping" then I'm ok, in this case, with making it optional. I agree about keeping preferences down where possible.
I'm guessing you were referring to this widely read essay about good user interfaces by Havoc Pennington. http://ometer.com/free-software-ui.html
- Alan k
participants (4)
-
Alan Horkan
-
Bryce Harrington
-
Carl Hetherington
-
Nathan Hurst