Vladimir Savic wrote:
Something even more annoying: node doesn't snap to path
Well, that would be possible, but unfortunately far from easy to
There's no visualization of snapping (pervert request -- I know
it wouldn't be
easy to implement) :)
Bulia and I had a discussion about this some time ago. We could have a
an icon in the statusbar that lights up when you're snapped and grays
out when not. From what I've heard this is the way Xara does it. We
could also have a dot blinking for a second, on the canvas, at the
position where the snapping occurred... That would really be cool, but
maybe this is also a bit too much eye-candy. It certainly wouldn't
improve the responsiveness I guess.
And don't know about that how hard would be to implement this
one... There was
some mentioning of current svn version slowness when dragging shapes over the
canvas (with complex drawing) because it wants to snap to everything. Would
it be even possible to determine how fast user wants to move something?
That would be a possible work around, but I'd rather fight the cause
itself instead of just the symptoms. I think there's still room for
improvement in the object-snapper. On top of that, the new lib2geom is
expected to improve the snapping responsiveness significantly. Don't
know when that is due though...
On Wednesday 22 August 2007 14:33:22 Johan Engelen wrote:
> In notepath.cpp from line 4051 onwards, the node type is determined.
As far as I can tell this class is not being used in the object-snapper,
so I guess we'll have to do without this.
> I think 2geom will replace all path representations in the end,
but I don't know.
Well, this is also what I expect, so I'll leave it as it
is now. It's
more efficient to implement "only snap to non-smooth nodes" when the
transition to lib2geom has completed. That might be a while...
> Right now, guide-grid intersections do not snap. Another thing is
angled snap lines. Angled guides are often requested, and the axonometric grid can also
use those snaplines.
It's on my to-do list:
- snapping to objects while dragging guides
- improve object-snapper performance (e.g. don't look for snapping
candidates and collect all paths/nodes for every single point to snap)
- implement constrained-snapping to objects
- snapping of grid/guide intersections (for this the snappers should not
simply return a snapped point, but sometimes return a snapped line. In
the snap-manager we can then combine multiple snapped lines to get an
- angled snap-lines
- visual feedback on snapping
- only snap to non-smooth nodes (after transition to lib2geom)