Need some input on bug #1540195 (snapping problem)
While looking into bug #1540195 I ran into some dilemma. This bug occurs when a bounding box is squeezed in between two vertical guides and makes it hard to pull the box out of its squeeze. For more details have a look at
http://sourceforge.net/tracker/index.php?func=detail&aid=1540195&gro...
The original post includes a nice sample file. This is what's going on:
1) Both the 4 points AND the boundingbox (also 4 points) are snapping, as requested in File -> Document Properties. 2) The origin is set to be at the boundingbox edge, as requested in File -> Inkscape preferences -> Tools -> Selector
This will not work in the situation described by bwalle. When snapping the boundingbox, the origin must be at the boundingbox. When snapping the nodes, the origin must be at the farthest opposite node. This is what's going wrong: when dragging the edge at the right, both the bounding box and two additional points will be trying to snap to the left guide, even when dragging the right edge far to the right. The left side of the boundingbox is not being transformed, as it's exactly at the origin. The two additional points though are slightly off the origin, and will be transforming almost invisibly. These are causing the troubles.
It's difficult to describe exactly what's going on, the best thing to do is to just try it.
This is what we could do: 1) calculate the origin ourselves, instead of obeying the preferences. Should this option even be removed from the preferences? Why is this option available to the user at all? 2) filter the snap points in the snapmanager, to only snap the points or boundingbox edges that are being moved. Points close to the origin could simply be discarded. 3) When dragging the boundingbox, we could feed the snapmanager only the points at the edge being dragged. But this doesn't handle the snapping of a complex object consisting of many points 4) ?
Does anyone have any suggestions or pointers?
Regards,
Diederik van Lierop
On 3/13/07, Diederik en Rezi <mail@...1689...> wrote:
- Both the 4 points AND the boundingbox (also 4 points) are snapping, as
requested in File -> Document Properties. 2) The origin is set to be at the boundingbox edge, as requested in File -> Inkscape preferences -> Tools -> Selector
[skipped]
This is what we could do:
- calculate the origin ourselves, instead of obeying the preferences.
Should this option even be removed from the preferences? Why is this option available to the user at all?
I think 1) is the best approach. That transform origin option is indeed very murky and hardly ever useful. It also has other bugs. I never liked it :)
Instead we're going to soon have another preference, similar but more general: whether the user wants to use geometric bbox (path only, no stroke) or visual bbox (with stroke). Correspondingly, the transform origin will _always_ be the edge of the chosen bbox, but the bbox itself may be different depending on user preference. This way those who prefer pure geometric bbox will have it in everything - in the visible frame, in snapping, and in transforms.
Further, perhaps by this change we will also be able to eventually get rid of the "snap bboxes/snap nodes" choice in document prefs. Selector will always snap bbox (although this bbox may be either visual as now, or including only nodes). Node tool will, naturally, always snap only nodes. Less preferences overall and a saner, more predictable experience. What do you think?
So right now, let's remove that transform origin preference, always assuming the origin to be at the bbox (but keeping in mind that soon, bbox calculations may change). Will this fix this bug? Or something else is neeed?
On 2007-March-13 , at 16:39 , bulia byak wrote:
On 3/13/07, Diederik en Rezi <mail@...1689...> wrote:
- Both the 4 points AND the boundingbox (also 4 points) are
snapping, as requested in File -> Document Properties. 2) The origin is set to be at the boundingbox edge, as requested in File -> Inkscape preferences -> Tools -> Selector
[skipped]
This is what we could do:
- calculate the origin ourselves, instead of obeying the
preferences. Should this option even be removed from the preferences? Why is this option available to the user at all?
I think 1) is the best approach. That transform origin option is indeed very murky and hardly ever useful. It also has other bugs. I never liked it :)
Instead we're going to soon have another preference, similar but more general: whether the user wants to use geometric bbox (path only, no stroke) or visual bbox (with stroke). Correspondingly, the transform origin will _always_ be the edge of the chosen bbox, but the bbox itself may be different depending on user preference. This way those who prefer pure geometric bbox will have it in everything - in the visible frame, in snapping, and in transforms.
Further, perhaps by this change we will also be able to eventually get rid of the "snap bboxes/snap nodes" choice in document prefs. Selector will always snap bbox (although this bbox may be either visual as now, or including only nodes). Node tool will, naturally, always snap only nodes. Less preferences overall and a saner, more predictable experience. What do you think?
I know the question was not asked to me but I just step in to say that this will really be a nice improvement. Right now snapping behavior is quite difficult to understand and gives unexpected results when snapping both to nodes and bbox on objects with a large stroke (strange thing to do probably but the possibility is offered by the prefs dialog). In addition, will objects measurements also change with this bbox preference change? For example, when snapping to nodes (i.e. in the future geometric bbox context) I would expect my objects to have dimensions which are multiples of grid units (10cm x 10cm for example) whatever the size of their stroke. With current system, which also measure stroke width (inaccurately when units are not px everywhere furthermore), it's difficult to actually use the position/ dimension spin buttons to place objects precisely. Good luck with these changes.
JiHO --- http://jo.irisson.free.fr/
On 3/13/07, jiho <jo.irisson@...400...> wrote:
I know the question was not asked to me but I just step in to say that this will really be a nice improvement. Right now snapping behavior is quite difficult to understand and gives unexpected results when snapping both to nodes and bbox on objects with a large stroke (strange thing to do probably but the possibility is offered by the prefs dialog).
Agreed. This needs to be fixed.
However, now that I think of it some more, there's a potential problem. We actually have three kinds of things that snap:
1 bounding boxes
2 path nodes
3 some special points, some of them specific to an object type, such as geometric center, rotation axis, tips of a star, or the baseline origin in a text.
Now, our proposal (separate bbox modes) is aimed at cleanly separating 1 and 2 so that they are still both available but not get into the way of each other. But what about 3? Right now, as I understand it, in the snapping options the special points are covered by "snap nodes", i.e. are combined with 2. But I think they should snap in Selector tool regardless of what kind of bbox is chosen. I.e. we should separate them from the "nodes" category and always snap them with Selector. However, this potentially can lead to bugs similar to this one: for example, if I'm using visual bbox (with stroke) and one of a star's tips is adjacent to bbox, but not exactly (i.e. it's basically coincides with the node). Does anyone have an idea of how to deal with this?
In addition, will objects measurements also change with this bbox preference change?
Yes, measurements will depend on what kind of bbox is chosen.
bulia byak wrote:
Instead we're going to soon have another preference, similar but more general: whether the user wants to use geometric bbox (path only, no stroke) or visual bbox (with stroke). Correspondingly, the transform origin will _always_ be the edge of the chosen bbox, but the bbox itself may be different depending on user preference. This way those who prefer pure geometric bbox will have it in everything - in the visible frame, in snapping, and in transforms. Further, perhaps by this change we will also be able to eventually get rid of the "snap bboxes/snap nodes" choice in document prefs. Selector will always snap bbox (although this bbox may be either visual as now, or including only nodes). Node tool will, naturally, always snap only nodes. Less preferences overall and a saner, more predictable experience. What do you think?
That would be great! This surely makes everything much cleaner. I'll try to calculate to correct origin. If that works nicely, the origin preference can be removed. I'm not fully sure if this will solve the bug, but we'll soon discover that..
Diederik
participants (4)
-
bulia byak -
Diederik en Rezi -
Diederik van Lierop -
jiho