Weird snapping toggling

[LucaDC]

I was playing with last new snapping group and options (thanks Diederik!) when I realized that sometimes global snapping toggling buttons are not respected. For example, if you have nodes snapping and snapping to, and item's rotation center enabled, then you toggle the global node snapping (all other nodes related buttons become inactive), a text center still snaps to nodes.

Anyway, apart from this the weird thing I found is in the attached file: if the text is outside the rectangle, I cannot snap the circle anywhere; but if I drag the text inside the rectangle, then the circle starts snapping everywhere (note that global bounding box and nodes snapping are disabled, but all their children are enabled, also if grayed out).
The process can be repeated dragging the text in and out and the result I get is always the same: text out -> not snapping, text in -> snapping.

Windows XP SP3, rev. 10486.

[su_v (suv-lp)]

Reproduced with Inkscape 0.48+devel r10485 on Mac OS X 10.5.8 (i386), default (new) preferences file

Snapping with 'Snap other points' to the rectangle when dragging the circle is enabled depending on the position of the moved text anchor of 'Ciao' (at least snapped to the bbox of the rectangle, or inside the rectangle).

OTOH moving the rectangle up so that the text is inside the rectangle does not enable 'Snap other points' snap mode/targets for the circle (i.e. it does not snap to the rectangle nor to the text). Only if the text anchor has been snapped at least once to the moved rectangle, the 'Snap other points' targets work when dragging the ellipse over the rectangle.

[su_v (suv-lp)]

> default (new) preferences file

Usually, I have 'Only snap the node closest to the pointer' setting active, but it does not work for the midpoint and rotation center snap mode/targets (since they have been moved to the 'Snap other points' group).

[LucaDC (lucadc)]

Thanks to Diederik for his effort in refactoring the snapping toggling buttons logic.
I was checking how things are changing and I expected the "snap guides" button alone (given its name) making guides origins snap to other guides and their origins, while the "Snap other points" global button (even alone) must be enabled too; so probably the right label for "snap guides" should be "snap to guides" or the behavior changed.
On the other hand, when "snap guides" is disabled, guides do not snap and are not snapped to in any case: it seems that the two buttons are "anded" so both must be enabled to have guides snap on something.

Request1: to enable paths intersections snapping, snap to path must be enabled too; sometimes this is annoying: is there a technical reason for this or could the two be made independent?

Request2: is snapping to a path's self intersection discarded for some reason?

Thanks.

[Diederik van Lierop (mail-diedenrezi)]

I was about to reply something along the line of "Hey Luca, you really should upgrade your Inkscape version more frequently because I already fixed this two days ago ;-)", but fortunately I found out that I missed something in that commit before I sent that reply.

In today's revision #10582 the guide toggling issue should have been fixed. There's only one button needed to snap guides, whether as a source or as a target. Please test, and keep an eye open for more regressions or annoyances like this. The refactoring of the snapping codes can cause a lots and lots of small issues like this, which make it impossible to oversee for me completely before committing new code.

W.r.t. request 1: These can indeed be made independent I guess, I will have a look at what it takes. Shouldn't require too much effort, but will not be fixed tonight ;-)

W.r.t. request 2: Snapping a path to itself has been implemented to some extent, but is quite tricky. In such a case you have a look at each path segment individually and see if it's stationary or moving. Maybe something changed when the node tool was redesigned last year? Or maybe this wasn't implemented in the node tool at all? Or are you referring to the pen or pencil tools?

[LucaDC (lucadc)]

Well, Diederik, so thanks a lot for the "predictive" fix :)
I've already tested many combinations, also many that I usually don't use (e.g. I've seen that bounding box related snappings don't interact with many others so you can't snap a bounding box corner to a node or to a center or to a baseline but didn't check if this was working before and if it could be a useful feature).
Actually I was going to write that some were not working but then I realized that the UI was having problems on buttons so a couple always got disabled when clicking any of the others and indeed teir corresponding snapping was never enabled; restarting Inkscape solved the problem so I don't think it's something related to the snapping code itself, and I can't reproduce it.

Req1: don't you already have a "predictive" improvement for this too? ;) The request comes from trying to reduce the amount of snapping sources-targets to the minimum required because having too many active makes Inkscape's redrawing and interaction terrible (not on your PC, I assume, having seen your compilation times...); the snapping to paths one is really heavy and moving an object around over others to snap to some intersection becomes a patience test for me.

Req2: I was referring to snapping to intersections of a single path to itself, like to the center of an "8" shape, not to snapping to a path while drawing it (never tried this, though); now only intersections between distinct paths are taken into account. I couldn't say if this was implemented before and if it could be useful because I've never really needed it. So I couldn't say if it's a bug or a new feature request.

[su_v (suv-lp)]

Re: snapping to paths vs snapping to path intersections

@Diederik - many thanks for separating the sources/targets for paths and intersections in r10585! I'd like to add a loosely related question:

There appear to be certain node snapping sources/targets which are always active now and can't be toggled off, which may interfere e.g. when snapping nodes to path only:
- 'corner' of rectangles
- 'quadrant point' of ellipses/circles
These snap sources/targets are also always snapping to the grid and guides (enabled by the group toggle 'Snap nodes, paths and handles'). When snapping to path, this prevents to "freely" snap to path near a corner point of a rectangle or a quadrant point of an ellipse (no problem after converting the shapes to path).

My question: is this intentional? Could corners and quadrant points be covered by cusp and smooth nodes, or an additional node snapping source/target be added (shape handles - i.e. the special on-canvas controls (handles) of Inkscape's custom shapes)?

<off-topic>
Any thoughts about adding a 'perpendicular/tangential to path' snap target? The math must be available - at least for LPEs (for a demo, see <http://vimeo.com/14955725> by prokoudine, from <http://libregraphicsworld.org/forum/viewthread.php?thread_id=64>)
</off-topic>

[Diederik van Lierop (mail-diedenrezi)]

On 08/28/2011 06:08 AM, ~suv wrote:
> Re: snapping to paths vs snapping to path intersections
>
> @Diederik - many thanks for separating the sources/targets for paths and
> intersections in r10585! I'd like to add a loosely related question:
>
> There appear to be certain node snapping sources/targets which are always active now and can't be toggled off, which may interfere e.g. when snapping nodes to path only:
> - 'corner' of rectangles
> - 'quadrant point' of ellipses/circles
> These snap sources/targets are also always snapping to the grid and guides (enabled by the group toggle 'Snap nodes, paths and handles'). When snapping to path, this prevents to "freely" snap to path near a corner point of a rectangle or a quadrant point of an ellipse (no problem after converting the shapes to path).
>
> My question: is this intentional? Could corners and quadrant points be
> covered by cusp and smooth nodes

That's been fixed (rev. #10588). Things like this have become very easy
with the refactored snapping code :-).

We still have the corners of images though, which only & always snap
when the "others" group has been enabled. I don't think these deserve a
separate button, and these cannot be tied to any of the other buttons in
that "others" group. It should however stay in that group, IMHO. We
can't put them in the bbox group because these points don't coincide
with the corners of the bbox if the image has been rotated. We could put
them in the nodes/paths group, but an image doesn't have a stroke. Maybe
I should just remove snapping of image corners completely from Inkscape?
If needed, one can always draw a rectangle around an image and have that
snap. I don't think this feature is being used all that much, or maybe
even no one has even discovered it ;-)

> <off-topic>
> Any thoughts about adding a 'perpendicular/tangential to path' snap target? The math must be available - at least for LPEs (for a demo, see<http://vimeo.com/14955725> by prokoudine, from<http://libregraphicsworld.org/forum/viewthread.php?thread_id=64>)
> </off-topic>

Well, that would be a completely new feature. Currently we only have
points as snap targets. Tangential snapping however requires lines as
snap targets. Besides, it would be relatively easy to have that
implemented for translating objects using the selector tool, but it
would become already a bit more complicated for stretching or skewing of
objects, as the angles of the lines will start to change. I don't think
all the math is already there. And what about the drawing of Bezier
paths? It's quite challenging to implement this all across inkscape,
that's why I've been putting this off. If I start implementing this for
translations and straight lines, then there's no way back for me when
our dear users start asking for more ;-)

[Diederik van Lierop (mail-diedenrezi)]

On 08/28/2011 09:01 PM, Diederik van Lierop wrote:
> Currently we only have points as snap targets.

That should have read "... as snap sources"

[su_v (suv-lp)]

@Diederik - thanks for your thoughts about tangential/perpendicular snapping (any further discussion should probably move to one of the related RFEs, e.g. bug #519391, bug #172134).

Issue as originally reported (no snapping of the circle's mid/center point to the rectangle's mid/center point) no longer reproduced (last tested with r10588), with 'Only snap the node closest to the pointer' setting off and on.

Snapping nodes to self-intersections ("8") when dragging objects works too in r10588, as does snapping to self-intersecting path segments in the node tool (assuming the dragged node doesn't affect the intersecting segments).

Can we close this report as 'Fix released' (AFAIU the original report was a regression in trunk only) or 'Fix Committed' (snapping to self-intersections worked in 0.47 both for dragging objects as well as for dragging nodes in the node tool, but doesn't work in 0.48.x)?

[LucaDC (lucadc)]

<off-topic>
@Diederik: I was going to ask for tangent snapping too but didn't dare doing it: thanks to ~suv. My idea was to limit this to guides so we could have a guide with a modificator (please, don't kill me) that when snapping to a path is kept tangent (or perpendicular, it's the same) while running along the path. Of course the guide should go back to its original angle in cusps or intersection points, where a tangent is not defined. Alternatively, with a second modificator (ok, now you can kill me) the guide could always keep its original angle and snap to the path where it's tangent or perpendicular. Then, having a tangent (or perpendicular) guide, it's a joke getting a different object, rotating it to the right angle (snapping to the guide) and placing it in the tangent point (the guide origin). A pretty close new feature that don't give a lot of space for other requests ;)
<off-topic>

[Diederik van Lierop (mail-diedenrezi)]

@LucaDC: please add this request to lp:519391 (which I've just assigned to myself). I will see what I can do, but I have some other bugs to fix first.

All other issues mentioned in this report should indeed have been fixed. I will mark this report as "Fix Released".

[LucaDC (lucadc)]

Thanks a lot.

[su_v (suv-lp)]

Some quick notes (despite that I did recommend to close the report) - when I have it sorted out in more detail, I'll give feedback on the mailing list <http://article.gmane.org/gmane.comp.graphics.inkscape.devel/37130>:

Diederik van Lierop wrote:
> I should just remove snapping of image corners completely from Inkscape?

No. (Please do not further reduce snapping features ;) ) Having to create a rectangle, remove its stroke, copy image and paste size on rectangle , center-align image and rectangle with 'Align&distribute', lower rectangle below image, group the two, to be then able to position a just imported bitmap image with the mouse by snapping it to guides, or the pixel grid (essential e.g. for export to bitmap to avoid blurring of the imported bitmap image and its edges) - repeated each time after importing or pasting a bitmap image from the clipboard? Please don't remove the snapping of image corners! (And no, usually I do not want to convert each import bitmap image into a pattern…)

~suv wrote:
> There appear to be certain node snapping sources/targets
> which are always active now and can't be toggled off
(…)
> My question: is this intentional? Could corners and
> quadrant points be covered by cusp and smooth nodes

A few hours of working with current builds later, I realize that I should have requested the opposite: In the select tool, please make nodes of dragged objects snap to path, to grid, to guides, to object/rotation centers etc. independent again - without requiring to have (cusp) nodes as active snap _targets_ as well.

The reduction of snap options [1] starts to interfere with my usual workflow (if I get around to work on my own documents): suddenly I have to zoom in much closer and then back out again far more often than I'm used to (which is a pain because the zoom history is currently is broken), and I even caught myself inserting temp layers above the current layer to be able to quickly hide/unhide objects whose nodes interfere when trying to drag other objects and snap their nodes e.g. to grid, or to guides, or rotation centers, or smooth nodes only, or midpoint of lines only - in regions where several objects overlap, with plenty of cusp nodes around. (Hiding objects of course is often not an option - if I want to snap to path (but not cusp nodes) or to midpoints of line segments or moved rotation centers but not cusp corners of that object etc.).

ISTM that earlier - before [1] - that it was a lot easier to selectively snap with precision (and max. control over what snaps to what). I start missing it ;)

[1] the distinction between snap sources and snap targets was removed

[su_v (suv-lp)]

> (Hiding objects of course is often not an option -
> if I want to snap to path (but not cusp nodes) or
> to midpoints of line segments or moved rotation
> centers but not cusp corners of that object etc.).

… not to mention path intersections (without having cusp nodes nearby interfere and prevent (or override) snapping e.g. a dragged line with its (cusp) end node to the intersection unless zoomed in close enough).