start point of paraxial path dosn't snap

[andreas_joachim]

Steps to reproduce:
- enable snapping mode
- enable "create a sequence of paraxial line segments"
- start drawing a line.
The start point doesn't snap to the grid.

In all the other modes the start point snaps to the grid, so i think it's a bug.

Version: 0.47
Operating System: Linux (openSuSE 11.2)
Arch: x86_64

Best regards
Andreas

[su_v (suv-lp)]

reproduced with Inkscape 0.47 r22583 and 0.47+devel r9092 on OS X 10.5.8

[Diederik van Lierop (mail-diedenrezi)]

Fixed as of rev. 9105.

Thanks for reporting Andreas!

[Diederik van Lierop (mail-diedenrezi)]

... and thank you too ~suv for reproducing it!

[su_v (suv-lp)]

tested and fix confirmed with Inkscape 0.47+devel r9105 - thx :)

After snapping the initial node to the grid, the first line segment defaults to 'vertical', with <Shift> it can be drawn horizontally (tested with default preferences and default snap settings).

[Diederik van Lierop (mail-diedenrezi)]

That's another bug, but I just fixed that too (rev. #9108). Now you should be able again to choose the orientation of the first segment by positioning the pointer where you want it, instead of having to resort to the shift-key

[su_v (suv-lp)]

r9108 bonus fix for changing direction of starting segment confirmed :)

nitpicking: the same happens after undoing a node with <Backspace> (<Shift> required to change direction when continuing the path) - sorry, I failed to notice it when testing previous revisions (not a regression, exists in 0.47 as well as r9105).

[Diederik van Lierop (mail-diedenrezi)]

That has been fixed too as of rev. #9116.

I never notice these bugs because I only know a fraction of all these tricks Inkscape can do (I never deleted the last node before), but that's because I spend more time coding than actually using Inkscape. So thanks for teaching me a new trick today ;-)

[su_v (suv-lp)]

…extending this report from the first node to the closing segment of a path drawn in paraxial mode:

Another issue I noticed while testing r9116:
a) if I use explicit snapping (e.g. to grid) for the second to last node, closing the path (by clicking on the highlighted starting node) adds an additional (unexpected) node close to the starting node
b) if I use implicit snapping to constraint (the second to last node is not explicitly clicked but implied or complemented by the paraxial mode) to close the path (by clicking on the highlighted starting node) the closing line segment is not always 'paraxial' i.e. it seems that snapping to constraint takes the direction but not the precise coordinates of the reference point for the second to last node that is inserted?

btw - (unrelated to this bug but noticed while testing its fix) - is it possible that the new pre-snap indicator feature can prevent scrolling of the canvas with the mouse scroll wheel when these conditions are met:
- snap delay is set to 0
- grid is visible (snap to grid is activated)
- one of the tools is active

[su_v (suv-lp)]

sorry for the noise - comment #8 about the closing segment:
a) related to bug #289774 and recently committed bug #208768 (-> is this really fixed?)
b) was already reported in bug #397353 “Last Polyaxial polyline segment not always parallel to axis.”

[Diederik van Lierop (mail-diedenrezi)]

a) When drawing a rectangle: If all but the first node were snapped to the grid, then in general the last segment you're drawing will not be aligned to the first node. To maintain the paraxial requirement, a L-shaped segment is needed to close the path, which introduces an additional node. If all nodes were snapped to the grid though, the last segment added doesn't have to be L-shaped and no additional node is required (I just fixed that in the latest revision)
b) Should also have been fixed by my latest commit.
c) I wouldn't expect that, but I'm not going to claim that this is not the case. The snap delay mechanism is a bit tricky, but as the delay is set to 0 this shouldn't matter. I will look into this, but if you find more evidence or a way to reproduce this then please let me know.

[Diederik van Lierop (mail-diedenrezi)]

c) Nevermind my comment, it's indeed reproducible and looks related to the snapindicator

[Diederik van Lierop (mail-diedenrezi)]

Scrolling should have been fixed as of rev. #9158

[su_v (suv-lp)]

fix confirmed with Inkscape 0.47+devel r9158 on OS X 10.5.8

I have not been able to reproduce the previously experienced loss of scroll wheel events with this revision. Thank you for your continuous work to improve and enhance snapping! Seeing a pre-snap indicator for the first node when creating new objects is great.

[su_v (suv-lp)]

@Diederik - could you take a look at an issue that seems related to the changes in r9158?

See bug #537249 “Using Spray tool crashes inkscape”: after the changes in revision 9158 Inkscape crashes when using the spray tool with small values for 'width'. I do not know if this needs to be fixed in the spray context or elsewhere…