Snap to grid and guide not working right (0.48.4)

Bug #1093739 reported by Rick Uhlenkott on 2012-12-26
56
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Diederik van Lierop
inkscape (Debian)
Fix Released
Unknown

Bug Description

Installed 0.48.4.1 yesterday, downloaded from SourceForge on 12/23. Noticed that most existing objects will not snap to grid or guides when moving them. Some existing objects will snap, but only at a certain node no matter where the cursor is. When drawing lines or shapes, the start and stop points do snap as expected, but none will snap when moving afterword. Tried on several drawings (all created in and all but the current one updated in previous versions) with same results.

Win. 7 64-bit with all updates.

su_v (suv-lp) on 2012-12-26
tags: added: snapping
su_v (suv-lp) wrote :

Not reproduced with Inkscape 0.48.4 on OS X 10.7.4 - snapping works the same as in 0.48.3.1 and earlier bug fix releases of 0.48.

Did you adjust the snap preferences and the snap settings for the current document on the snap controls bar as needed?
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Snapping.html#Snapping-Objects>

> Noticed that most existing objects will not snap to grid or guides when moving them.

You need to activate snap targets on the snap controls bar to define 'what' snaps to the grid (e.g. cusp or smooth nodes, rotation center, text anchor, etc.), when moving an existing object with the mouse while having the grid visible.

> Some existing objects will snap, but only at a certain node no matter where the cursor is.

That depends on your preference settings for snapping (Inkscape Preferences > Snapping):
- '[x] Only snap node closest to the pointer' (off by default)
- Weight factor: determines which solution to prefer when multiple snap solutions are found

> all created in and all but the current one updated in previous versions

Which version is "previous" referring to? Could you attach such sample files?

Changed in inkscape:
status: New → Incomplete

All snap settings, controls, and preferences are unchanged from what I had
been using, as far as I can tell. I did not make any recent changes to
them myself, but the behavior has changed. Have not even had to look at them
again until now.

Previous versions refers to the last couple of 0.47 stable releases,all
0.48 stable releases, and development version 0.48.3.1.1, which was the last
version I used before this one.

I have attached the current file (WAGNER...) that I was working on in the
0.48.3 version and moved to this one, and some files not worked on in this
one, including the pattern file I use to start these particular drawings
with (open and SAVE AS a new name before I start the new drawing).

In a message dated 12/26/2012 2:25:41 A.M. Mountain Standard Time,
<email address hidden> writes:

Not reproduced with Inkscape 0.48.4 on OS X 10.7.4 - snapping works the
same as in 0.48.3.1 and earlier bug fix releases of 0.48.

Did you adjust the snap preferences and the snap settings for the current
document on the snap controls bar as needed?
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Snapping.html#Snapping-Objects
>

> Noticed that most existing objects will not snap to grid or guides
when moving them.

You need to activate snap targets on the snap controls bar to define
'what' snaps to the grid (e.g. cusp or smooth nodes, rotation center, text
anchor, etc.), when moving an existing object with the mouse while having the
grid visible.

> Some existing objects will snap, but only at a certain node no matter
where the cursor is.

That depends on your preference settings for snapping (Inkscape
Preferences > Snapping):
- '[x] Only snap node closest to the pointer' (off by default)
- Weight factor: determines which solution to prefer when multiple snap
solutions are found

> all created in and all but the current one updated in previous
versions

Which version is "previous" referring to? Could you attach such sample
files?

** Changed in: inkscape
Status: New => Incomplete

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1093739

Title:
Snap to grid and guide not working right

Status in Inkscape: A Vector Drawing Tool:
Incomplete

Bug description:
Installed 0.48.4.1 yesterday, downloaded from SourceForge on 12/23.
Noticed that most existing objects will not snap to grid or guides
when moving them. Some existing objects will snap, but only at a
certain node no matter where the cursor is. When drawing lines or
shapes, the start and stop points do snap as expected, but none will
snap when moving afterword. Tried on several drawings (all created in
and all but the current one updated in previous versions) with same
results.

Win. 7 64-bit with all updates.

To manage notifications about this bug go to:
https://bugs.launchpad.net/inkscape/+bug/1093739/+subscriptions

AFAICT some of the backported changes from trunk for 0.48.4 seem to have modified a basic snap behavior in the select tool context of the stable release branch - i.e. introduced some of the newer snap behavior from the development version like dropping the distinction between 'what' snaps and snap targets: snapping cusp nodes to grid when dragging an object or a complex group for example now requires to activate 'Snap cusp nodes' too - this is indeed different from the prior stable version Inkscape 0.48.3.1.

Additionally, there seems to be no more 'Convex hull' snapping to grid (default snapping preferences) when dragging a complex group with e.g cusp node snapping and grid active.

Needs further investigation with regard to what is intentionally changed behavior, and what might be considered a regression in the context of the stable release branch - setting bug status to 'Confirmed' for now.

Changed in inkscape:
status: Incomplete → Confirmed

Yes, ~suv is right (as usual ;-)). In previous versions, enabling the "snap nodes, paths, and handles" button was sufficient to snap the nodes of a selection to for example a grid, but this didn't allow for specifying whether cusp nodes or smooth nodes were to be snapped. At some point this was changed (don't know in which version exactly though), and now you have to enable either or both of the cusp/smooth nodes buttons. That's likely what you're experiencing. More changes are planned in this particular area of the snapping gui, to make this more explicit and clear, and at the same time to make things more configurable. Haven't had time though to work on this yet.

The other part that ~suv mentioned is that for large selections, we can't consider all nodes for snapping. Snapping a few hundred nodes is simply too much to be handled within a second or so, so Inkscape has to be clever. In the past, only the convex hull of such a large selection was used for snapping, but this could still contain quite a number of nodes and still needed to be calculated. On top of that, in most cases that didn't make that much sense to the user after all. We could just as well have taken any other arbitrary subset of nodes. Chances were that the node that needed snapping wasn't part of the selection, which is annoying. In the current versions, you just grab the selection close to node that you want to snap. That gives you much more control of the snapping, and can be handled by Inkscape in milliseconds. "Only snap node closest to the mouse pointer" has to be enabled though (in the preferences). Also, in such a case, you can use the tab key to cycle through the nodes. Pressing tab once will make the node second closest to the mouse pointer snap, and you can continue pressing tab (or shift-tab) as long as needed to get to the node you like.

Does this help you?

Changed in inkscape:
assignee: nobody → Diederik van Lierop (mail-diedenrezi)
su_v (suv-lp) wrote :

On 30/12/2012 10:39, Diederik van Lierop wrote:
> In previous versions, enabling the "snap nodes, paths, and handles"
> button was sufficient (…)

> At some point this was changed (don't know in which version exactly
> though), and now you have to enable either or both (…)

It's a rather big (and to me unexpected) change in behavior for a minor bug fix release. Sorry to have missed it before the release - I should have noticed earlier :/

IIRC from the tests done earlier for this report, the changes occurred in the stable release branch between 0.48.3.1 and 0.48.4, in r9936. The basic refactoring of snapping itself happened in trunk only [1], and had not been backported to the stable release branch for earlier bug fix releases.

> (…) in such a case, you can use the tab key to cycle through the nodes.

This feature for example doesn't work for me in stable Inkscape 0.48.4 - 'Tab'/'Shift+Tab' cycles the selection itself (it seems to work as described only in trunk builds).

Could you add documentation to the release notes for 0.48.4 about the scope of the changes wrt to snapping?

---
[1] see also bug #927898 reporting the same issue for trunk (“snap to guides no longer working for path nodes or rotation origin”).

Found out what's going on:

In trunk, two inactive lines were removed: lines 446 and 447 of selection.cpp (see http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11937)

In 0.48.4 however, these lines (434 and 435 in selection.cpp) were still active and needed, but accidentally removed when applying the backport from trunk (see http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_48_BRANCH/revision/9934).

So yes, this is indeed a regression! I will add this to the release notes.

~suv, do you have a checkout of the 0.48.x branch at hand to reinstate these two lines?

su_v (suv-lp) wrote :

> ~suv, do you have a checkout of the 0.48.x branch at hand to
> reinstate these two lines?

Yes, I have an up-to-date 0.48.x branch here, and can push the attached diff if you want me to… (currently rebuilding 0.48.x branch with diff applied - haven't tested it yet).

su_v (suv-lp) wrote :

> currently rebuilding 0.48.x branch with diff applied

AFAICT based on a quick test:
1) the old snap behavior with regard to 'what' snaps and snap targets is restored, but not the convex hull type of (node) snapping for complex groups.
2) with the provided sample files (e.g. 'N DRAWING PATERN.svg' from comment #2), it seems impossible to achieve a controlled snapping to the grid of the more complex, nested groups, even if changing the default snap settings to 'Always snap node closest to the pointer'.

Since 'convex hull' doesn't set in either, snapping with 'Nodes & handles' to grid while dragging a group containing other groups of paths doesn't really work yet in the release branch - tested with attached reduced test case, and compared with snapping in 0.48.3.1, original 0.48.4 and current trunk (r11998).

ad. 1) That's as expected
ad. 2) This is somewhat inevitable for such large selections of nodes,
right? This was already awkward, even with the convex hull snapping
being present. The convex hull would allow to snap reproducibly, but
would in many cases not contain the nodes to be snapped. This has been
improved in v0.49. Workaround for now to keep things snapped to a grid
is to use alt-dragging (will snap to multiples of the grid pitch), but
of course this will only work for objects that have been snapped before
being added to the larger selection

You're patch looks fine, thanks for creating it. Please go ahead and
commit it!

Thanks,

Diederik

On 12/30/2012 05:49 PM, ~suv wrote:
> > currently rebuilding 0.48.x branch with diff applied
>
> AFAICT based on a quick test:
> 1) the old snap behavior with regard to 'what' snaps and snap targets is restored, but not the convex hull type of (node) snapping for complex groups.
> 2) with the provided sample files (e.g. 'N DRAWING PATERN.svg' from comment #2), it seems impossible to achieve a controlled snapping to the grid of the more complex, nested groups, even if changing the default snap settings to 'Always snap node closest to the pointer'.
>
> Since 'convex hull' doesn't set in either, snapping with 'Nodes &
> handles' to grid while dragging a group containing other groups of paths
> doesn't really work yet in the release branch - tested with attached
> reduced test case, and compared with snapping in 0.48.3.1, original
> 0.48.4 and current trunk (r11998).
>
> ** Attachment added: "1093739-nested-groups-snap-with-nodes-to-grid-1.svg"
> https://bugs.launchpad.net/inkscape/+bug/1093739/+attachment/3470917/+files/1093739-nested-groups-snap-with-nodes-to-grid-1.svg
>

> ad. 2) This is somewhat inevitable for such large
> selections of nodes, right?

Not really - with Inkscape 0.48.3.1, as well as with current trunk, 'Only snap node closest to the pointer' usually works reliably (i.e. the node closest to the point where the group was grabbed will snap to the closest available targets).
Using 'Only snap node closest to the pointer' either in stable 0.48.4 combined with 'Snap to cusp nodes' or in 0.48.4+patch, the group in the attached sample file from comment #8 no longer snaps as expected - at all: Inkscape snaps with some (seemingly random) node far away from the pointer, and this doesn't not change if the group is grabbed at a different location.
The trigger seems to be group(s) of paths inside the group being dragged.

> You're patch looks fine, thanks for creating it. Please go ahead
> and commit it!

Done (r9941).

Changed in inkscape:
milestone: none → 0.48.5
status: Confirmed → Fix Committed
su_v (suv-lp) on 2012-12-31
tags: added: regression
summary: - Snap to grid and guide not working right
+ Snap to grid and guide not working right (0.48.4)
su_v (suv-lp) wrote :

New report about snapping issue in 0.48.4 - related to comments #8 and #10:
- Bug #1104272 “Lowest object refuse snap to grid - "Only snap the node closest to the pointer" is ignored”
  <https://bugs.launchpad.net/inkscape/+bug/1104272>

The issue noted in comment #10 should have been fixed as of rev. 9947 in the v0.48.x branch, and will be part of Inkscape v0.48.x

jazzynico (jazzynico) on 2013-12-05
Changed in inkscape:
importance: Undecided → Medium
Changed in inkscape:
status: Fix Committed → Fix Released
Changed in inkscape (Debian):
status: Unknown → Confirmed
Changed in inkscape (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.