Hi,
Some major changes were planned to the selector tool, see e.g. Bulia's list of changes in.
http://sourceforge.net/tracker/?func=detail&aid=1589436&group_id=934...
you'll have to scroll down a bit....
One of them was to have an option to snap either the APPROXIMATE_BBOX or the GEOMETRIC_BBOX, which would enable us to remove the confusing snap nodes / snap bbox option. In the future snapping to the grid/guide/path will always occur when the relevant grid/guide/path is visible, but that's for later.
For now I've implemented the two bbox modes hard coded in the constructor of Inkscape::Seltrans in seltrans.cpp (at line 98). You can select the behavior you'd like and experiment with it, but for default I left at APPROXIMATE_BBOX. If you all agree on this new behavior then I will change the preferences in the UI, but I've never touched the UI before so I would like to have some feedback before diving into this. Along the way I've solved various snapping bugs, but probably also introduced some fresh ones. Let me know if you find one!
There are some things to note:
- If you choose the GEOMETRIC_BBOX, the handles will now be located at the GEOMETRIC_BBOX (they used to be always located at the APPROXIMATE_BBOX) - The origin option is not being used and will be deleted soon. - The origin doesn't drift away any longer (unless the object is being mirrored while scaling/stretching and APPROXIMATE_BBOX has been selected, but I still need to fix that) - The stroke width scales while dragging, even when the corresponding button has been disabled. When releasing the handle everything turns out just fine, but while dragging it still looks like snapping wrong. I don't think this is due to the selector tool though. Has anyone looked into this before?
Regards,
Diederik van Lierop
On 4/8/07, Diederik en Rezi <mail@...1689...> wrote: http://sourceforge.net/tracker/?func=detail&aid=1589436&group_id=934...
you'll have to scroll down a bit....
One of them was to have an option to snap either the APPROXIMATE_BBOX or the GEOMETRIC_BBOX,
Rather, to _use_ either the APPROXIMATE_BBOX or the GEOMETRIC_BBOX - they should be used in most places, not only for snapping (visible frame, transforming, alignment, measuring dimensions etc.). We need to make sure that all relevant places are in sync with regard to this setting.
For now I've implemented the two bbox modes hard coded in the constructor of Inkscape::Seltrans in seltrans.cpp (at line 98). You can select the behavior you'd like and experiment with it, but for default I left at APPROXIMATE_BBOX. If you all agree on this new behavior then I will change the preferences in the UI, but I've never touched the UI before so I would like to have some feedback before diving into this.
Thanks a lot! This was a sadly neglected area, it's extremely healthy to see all your fixes coming in :)
- If you choose the GEOMETRIC_BBOX, the handles will now be located at
the GEOMETRIC_BBOX (they used to be always located at the APPROXIMATE_BBOX)
Correct
- The origin option is not being used and will be deleted soon.
Correct
- The origin doesn't drift away any longer
Very cool - I worked on that before, but I never could fix it so that both transform origin settings would work without any drift. Now it's going to be MUCH easier when the bbox option controls everything and not just transform origin.
- The stroke width scales while dragging, even when the corresponding
button has been disabled. When releasing the handle everything turns out just fine, but while dragging it still looks like snapping wrong. I don't think this is due to the selector tool though. Has anyone looked into this before?
Certainly. It's one of the oldest bugs in our tracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=969406&grou...
The reason is that for speed, while you are dragging transformation handle, seltrans does not update the repr of the object, but only the object itself. Therefore stroke width adjustments are not written to the object's style. And the display engine takes stroke width from the style and unconditionally scales it by the object's transform. Therefore the displayed stroke width grows as you scale it up. Once you release mouse, stroke width is adjusted and fully written, so the display becomes correct.
- The origin option is not being used and will be deleted soon.
Done. Apparently, there's nothing to be removed from the preferences-skeleton, right? I just removed "_t_sel_org_edge.init". I'd appreciate it if anyone could shed some light on this... E.g. what about translation files? Will these be synced automagically?
- The origin doesn't drift away any longer
This now also holds when mirroring occurs while dragging the handles around
- The stroke width scales while dragging, even when the corresponding
button has been disabled. When releasing the handle everything turns out just fine, but while dragging it still looks like snapping wrong. I don't think this is due to the selector tool though. Has anyone looked into this before?
Certainly. It's one of the oldest bugs in our tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=969406&grou...
The reason is that for speed, while you are dragging transformation handle, seltrans does not update the repr of the object, but only the object itself. Therefore stroke width adjustments are not written to the object's style. And the display engine takes stroke width from the style and unconditionally scales it by the object's transform. Therefore the displayed stroke width grows as you scale it up. Once you release mouse, stroke width is adjusted and fully written, so the display becomes correct.
OK, I see the problem here. I'm not going to try tackling this one ;-)
Thanks for your help Bulia, I couldn't have solved these bugs without your help!
Regards,
Diederik
participants (3)
-
bulia byak -
Diederik en Rezi -
Diederik van Lierop