Ctrl modifier can prevent snapping in some cases

[Vladimir Savic]

Holding CTRL keyboard modifier pressed when drawing line can prevent snapping to occur.

Case that annoys me most:
1. Draw rectangle
2. Pick freehand drawing tool
3. Move mouse cursor over right side of rectangle and wait for a snapping indicator to appear
4. Click to start line drawing
5. Move cursor over the opposite rect (left) side WITH ctrl key pressed
6. Observe how snapping is impossible now.

[su_v (suv-lp)]

> 3. Move mouse cursor over right side of rectangle
> and wait for a snapping indicator to appear

Which snap targets do you have enabled?
Which Inkscape version do you use?

[su_v (suv-lp)]

> 6. Observe how snapping is impossible now.

Not reproduced when using 'Snap nodes and handles' with 'Snap to paths', snapping preferences and document snap settings are default (tested with Inkscape 0.48+devel r9692 on OS X 10.5.8).

[Vladimir Savic (vladimir-firefly-savic)]

Sorry for lack of informations.
Running most recent bzr on linux ubuntu 10.04 here.
As of snapping options, turn every option on!

[su_v (suv-lp)]

> As of snapping options, turn every option on!
I see… why would you do that ;-) ? (I usually only have the basic ones enabled and activate the others if needed)

> 2. Pick freehand drawing tool
> 4. Click to start line drawing

Do you mean click-dragging to draw in freehand mode or click - click to draw a straight line? Pressing 'Ctrl' seems to stop a freely drawn curved line independently of any snapping options (I don't know why it has any effect at all in that mode: the 'Ctrl' modifier is used to a) create dots with 'Ctrl+click' or b) draw a (x- or y-) constrained straight line (2 clicks).

> 6. Observe how snapping is impossible now.

Not reproduced with every snapping option on the snapping toolbar enabled, when drawing a constrained straight line with the pencil/freehand tool - but I noticed that my rectangle had minimally rounded corners. ->

It seems the same issue as reported in Bug #590486 “[snapping] snap node to midpoint of 'z' segment closing a path fails”: the closing segment of a rectangle is now a 'z' element (the left vertical edge) which fails for midpoint snapping and apparently also for constrained snapping - drawing the freehand line from bottom to top or left to right works as expected (with 'Ctrl' pressed).

[Vladimir Savic (vladimir-firefly-savic)]

> I see… why would you do that ;-) ?
You made me try disabling some of them as well, but no luck with snapping anyway...

> Do you mean click-dragging to draw in freehand mode or click - click to draw a straight line?
Click - Click, as you call it.

Video demonstration attached! Video=1000*pictures*time! :)

[su_v (suv-lp)]

Reproduced with other shapes/paths that have a straight closing segment (e.g. a star or polygon): constrained snapping (to path) when drawing a path with the pencil or pen tool fails for the closing 'z' segment.

[su_v (suv-lp)]

> … fails for the closing 'z' segment.

To clarify: … fails when snapping in constrained mode (angle limited to the rotation snaps angle set in the preferences) to a path segment that is stored as 'z' in the path data (SVG source).

[Vladimir Savic (vladimir-firefly-savic)]

Can we treat this as a regression then? I'd like to see some raised priority here...

[Diederik van Lierop (mail-diedenrezi)]

There are a few things I observe here:
1) snapping to closing segments still fails apparently. I thought we had that fixed :-(
2) constrained snapping (i.e. with ctrl) only snaps to paths, not to nodes yet (I still have to implement that)
3) when trying to snap to e.g. a vertical path using a vertical constraint, we need to calculate an intersection. But the lines are coincident, so I'm not sure what intersection will be found. This might also be sensitive to rounding errors, and overall leading to unpredictable results. Or in this case very predictable results: no snapping.

[Vladimir Savic (vladimir-firefly-savic)]

I don't understand point no. 3. I can't even imagine constraint vertical movement meeting perfectly vertical line... hmmm

[Diederik van Lierop (mail-diedenrezi)]

2) has been implemented, as of rev. #9696

Vladimir, do you think we raised the priority to an acceptable level ;-) ?

[Vladimir Savic (vladimir-firefly-savic)]

Nope! You still have to finish No.1 and 3 (whatever it covers)... :P
Kidding. Thank you Diederik for fast response! :)

[su_v (suv-lp)]

Regression in Inkscape 0.48+devel r9696 on OS X 10.5.8 (not reproduced with r9695)

Inkscape hangs or crashes in the node tool when moving a selected node along a line collinear with the node handle (Ctrl+Alt+drag):

1) set snap node to cusp nodes
2) draw a horizontal line (2 nodes)
3) switch to the node tool and select the right end-node
4) extend the line by moving the node with 'Ctrl+Alt+drag' along the node handle (in case of a line segment, the node used to move constrained to the direction of the line)

-> Inkscape crashes or freezes

Console messages vary: either just

 Emergency save activated!

or for example:

Emergency save activated!
inkscape-bin(98585,0xa0492720) malloc: *** error for object 0x61f22a0: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
inkscape-bin(98585,0xa0492720) malloc: *** error for object 0x61f22a0: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
inkscape-bin(98585,0xa0492720) malloc: *** error for object 0x61f22a0: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

Emergency save document locations:
  /Users/suv/New document 1.2010_08_11_06_02_00.0.svg
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can fix it.

(inkscape-bin:98585): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

[su_v (suv-lp)]

different traceback from another crash (iirc in this case all snap options had been enabled, crash also happened when moving a node with 'Ctrl+Alt+drag' in the node tool)

[Diederik van Lierop (mail-diedenrezi)]

Cannot reproduce this, but that might because I've compiled Inkscape with different options.

I've just made snapping in Inkscape a bit more secure with respect to invalid pointers, which is what you might have run into. Could you please test rev. #9697?

Thanks for attaching the backtrace, that's been very helpful.

[su_v (suv-lp)]

r9697 doesn't help: now even the pre-snap indicator causes Inkscape to crash:
My default template has a grid enabled and visible. Just switching to the pen tool and moving the cursor across the canvas in a new document triggers a crash.

[su_v (suv-lp)]

The error when Ctrl+Alt+dragging a node in the node tool still exists in r9697:

1) open attached drawing, select path
2) switch to node tool and select the node at the right end
3) Ctrl+Alt+drag the node to extend the line horizontally to the right

-> crash in
SnapManager::findBestSnap(Inkscape::SnapCandidatePoint const&, SnappedConstraints const&, bool, bool, bool) const

[su_v (suv-lp)]

Backtrace from crash when Ctrl+Alt+dragging a node in the node tool with r9697

My compile options as output by configure:
        Compiler: g++-4.2
        CPPFLAGS: -Werror=format-security -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2 -I/Volumes/blue/mp-inkscape/with-a-long-long-long-directory-name/include
        CXXFLAGS: -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -O3 -Wall
        CFLAGS: -Wno-pointer-sign -O3 -Wall
        LDFLAGS: -L/Volumes/blue/mp-inkscape/with-a-long-long-long-directory-name/lib

[Diederik van Lierop (mail-diedenrezi)]

That's another crash, because of an error in my last commit. Sorry for that. It has been fixed however in revision 9701.

I usually compile with the -g flag, because that makes debugging easier and because it produces very detailed traces. It also hides some bugs though, which was also the case here. When I omitted that flag Inkscape immediately crashed here too.

[su_v (suv-lp)]

None of the crashes described in previous comments (13, 14, 16, 18) reproduced with r9701 on OS X 10.5.8 :)

[Diederik van Lierop (mail-diedenrezi)]

Constrained snapping to closing segments (i.e. snapping along a line or circle, often invoked by holding CTRL or by rotating using the selector tool) should work as of rev. #9788.

Could one of you test this, and see if it behaves as expected? You've all proven to be far better at testing than I am ;-)

[su_v (suv-lp)]

Fix confirmed with Inkscape 0.48+devel r9788 on OS X 10.5.8, no regressions found so far.

(note: my local builds currently are compiled with the '-g' flag too, see comment #19)

[su_v (suv-lp)]

@Diederick - since this is a regression in 0.48, do you have plans to backport it to the 0.48.x branch, or do the changes depend on other recent commits to the trunk?

[su_v (suv-lp)]

sorry for the misspelling:
s/Diederick/Diederik/

[Diederik van Lierop (mail-diedenrezi)]

No problem, that's not uncommon ;-)

The added code might introduce new bugs because it's not really a one-liner On top of that the regression was annoying but not that serious IMHO, so for now I don't have any plans for backporting.