Pattern Along Path LPE: width parameter only adjustable on-canvas

[su_v]

In recent builds of trunk and 0.92.x, adjusting the width parameter of the pattern numerically in the 'Path Effects' dialog no longer works - adjusting the width with the on-canvas handle still works as expected.

Steps to reproduce:
1) launch current trunk or stable 0.92.x
2) draw a path for the pattern, copy to clipboard
3) draw another path, keep it selected
4) open 'Path > Path Effects' and apply 'Pattern along Path' effect
5) in the 'Path Effects' dialog, paste the pattern path from clipboard
6) in the 'Path Effects' dialog, set 'Width' parameter for the pattern to '2.00'

Expected result:
Width of the applied path effect changes based on new width parameter value

Actual result:
The width stays unchanged.

7) switch to the node tool, adjust the width parameter on-canvas
-> in the 'Path Effects' dialog, the value of width parameter updates accordingly.
8) in the 'Path Effects' dialog, reset the width parameter to '1.00'
-> width of the applied path effect does not change, nor can it be reset to the default (1.00).

Based on tests with archived builds (lp:inkscape/0.92.x, OS X 10.7.5):
- not reproduced with rev <= 15053,
- reproduced with rev >= 15055;
this regression is likely exposed as (unintended) side-effect of revision 15054:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15054

Also reproduced with trunk (lp:inkscape r15104) on Ubuntu 14.04.5 LTS.

[Jabiertxof (jabiertxof)]

I go into this weekend.

[Jabiertxof (jabiertxof)]

This patch fix the problem.
Mostly is a revert to the broken revision.
I do this code because in node editing paths with pattern along path applied, if I move the second node of the path in the first editing, give strange position of the node. Not know why but this not happends now. Anyway now Im not now in Gnome, but think this is not important in this case.

[Jabiertxof (jabiertxof)]

A little tweak

[su_v (suv-lp)]

Patch from comment #3 tested successfully with lp:inkscape/0.92.x r15074 on OS X 10.7.5.

On 2016-09-08 22:28 (+0200), Jabiertxof wrote:
> I do this code because in node editing paths with pattern along path
> applied, if I move the second node of the path in the first editing,
> give strange position of the node. Not know why but this not happends
> now.

This is reproducible (though not consistently), and probably should be tracked in a separate report (needs fixing without breaking other aspects of the path effect(s)).

[Jabiertxof (jabiertxof)]

Ok su_v I do another patch that fix also the node editing.

[Jabiertxof (jabiertxof)]

I hope this patch fox the two issues.

[su_v (suv-lp)]

Erratic node-editing of second node still reproduced with lp:inkscape/0.92.x r15074 + fix-bug-1621234.v3.patch

Steps to reproduce:
1) launch 0.92.x with default (new) prefs, default new doc (en_US)
2) open the Path Effects dialog (Shift+Ctrl+&)
3) zoom to 100% ('1')
4) switch to the Bezier tool ('B')
5) select 'Ellipse' as shape
6) draw e.g. a sinus-like curve (over one period):
   click once on canvas for (cusp) start node
   click-drag for second (smooth) node
   click-drag for third (smooth) node
   click once for (cusp) end node; finish path
7) switch to select tool ('S')
8) switch to node tool ('N')
9) drag second node of the skeleton path

--> result:
a) inkscape pauses briefly, and does as instructed
or
b) inkscape pauses briefly, then displaces the selected (dragged) node (usually near/outside page origin - lower left corner of the page area)

This reproduces not consistently -> several attempts might be needed.

[Jabiertxof (jabiertxof)]

@su_v, thanks for testing it.

I couden't reproduce it I try it several times and no problem with last patch.

Are you sure apply v3 patch? Sorry if disturb you with the question.

[su_v (suv-lp)]

On 2016-09-09 11:54 (+0200), Jabiertxof wrote:
> Are you sure apply v3 patch? Sorry if disturb you with the question.

I checked twice before replying (see also attached report about changes in local branch).

Please note that I only tested with stable 0.92.x branch (using GTK2/X11 on OS X 10.7.5), and not with trunk (current trunk is _very_ awkward to use with the ancient GTK3 version shipping with Ubuntu 14.04 LTS; and I avoid as much as possible launching the VM with Ubuntu 14.04 to test a recent build of trunk).

[Jabiertxof (jabiertxof)]

@su_v ok as usual :).
Could you try this last patch?
I couldent reproduce in my machine but maybe this fix it.

[Jabiertxof (jabiertxof)]

and thanks for your time!

[su_v (suv-lp)]

Erratic node-editing of second node still reproduced with lp:inkscape/0.92.x r15074 + fix-bug-1621234.v4.patch

Additional notes:
- Appears to only happen if Path Effects dialog was opened at least once in the current session.
- The actual displacement seems to dependent on (impatient) mouse/pointer movements while Inkscape appears to pause during the initial drag of the second node of the skeleton path.
- If the Path Effects dialog was never opened yet in the current session, node-editing is smoothly (no pauses, no displacement).

Feel free to ignore these observations if the erratic node-editing behavior is not reproducible with patched lp:inkscape/0.92.x on other platforms (Linux, Windows) which use more modern compiler toolchains compared to my local builds.

[Jabiertxof (jabiertxof)]

I try to revert to 15054. to get my system whit the code that make this strange beahabiour in 2 node.
Now I couldent reproduce :( again.

Not sure how to fix it :( anyway I think is a good idea apply patch to fix the original bug.

Maybe this weekend I could setup a virtual system. @su_v: Could refresh me your version of ubuntu
 please.

[su_v (suv-lp)]

On 2016-09-09 14:04 (+0200), Jabiertxof wrote:
> @su_v: Could refresh me your version of ubuntu please.

I do not understand what kind of information you want from me, and for
what purpose (in the context of this bug report).

[Jabiertxof (jabiertxof)]

@su_v: One question more. I remove unnecesary headers on 0.92.x patternalongpath LPE. Could you try the last patch if still happends the bug?
Thanks in advance.

[Jabiertxof (jabiertxof)]

@su_v. I want to create a ubuntu virtual machine this weekend and want to use similar env than you to test.

Cheers, Jabier.

[su_v (suv-lp)]

On 2016-09-09 14:19 (+0200), Jabiertxof wrote:
> One question more. I remove unnecesary headers on 0.92.x
> patternalongpath LPE. Could you try the last patch if still happends
> the bug?

Yes - lp:inkscape/0.92.x r15075 + fix-bug-1621234.v4.patch still
reproduces the issue with erratic behavior when node-editing the second
node for the first time.

On 2016-09-09 14:35 (+0200), Jabiertxof wrote:
> I want to create a ubuntu virtual machine this weekend and want to
> use similar env than you to test.

My recent tests with lp:inkscape/0.92.x are _not_ on Ubuntu - they are
still on OS X 10.7.5 (with a rather old version of clang).

<off-topic>
Trunk no longer compiles on this version of OS X with the system
compiler toolchain (due to C++11 requirement). If I want to test trunk,
I currently use an old VM with Ubuntu 14.04 LTS.

I only mentioned Ubuntu to explain why testing patches with inkscape
trunk is currently not a pleasant experience for me (mostly due to the
outdated version of GTK3 (3.10.8) which is provided by Ubuntu 14.04
LTS). The Inkscape project IMvHO should stop supporting older GTK3
versions rather sooner than later. This of course likely would mean to
cut off support for some stable (LTS) Linux distros, too.
</off-topic>

[su_v (suv-lp)]

Another description of what is happening when node-editing goes wrong with a path drawn using the 'Ellipse' shape:

Initially, the width parameter of the just drawn path (with shape 'Ellipse') is incorrectly shown in the 'Path Effects' dialog as '1.00' (does not match the generated output on-canvas). When node-editing the skeleton path later on, the correct value is filled into the width widget in the GUI. Node-editing goes wrong at the time the width is changed in the GUI (pauses, displaces the selected node or erratically switches selection to a different node, or extracts node handles where none had been, etc). Possibly the updating width widget captures focus (off the canvas), or otherwise confuses the node-tool about the location / scale /scope of the current editing.

Note that in a new document based on the default template, the default width of the pattern is 0.265 (for paths drawn with 'Ellipse' pattern/shape).

Workarounds for those affected (with the patch from comment #11 applied to lp:inkscape/0.92.x):
a) deselect the path, and re-select it again (this will update the width parameter in the Path Effects dialog)
or
b) do the first node-edit not with the mouse but with the cursor keys (e.g. nudge the selected node a tick upwards and back down again): this will force the width parameter to be updated correctly in the Path Effects dialog.
After having used one of the workarounds, node editing of this particular path with Pattern-Along-Path LPE applied works as expected.

[Jabiertxof (jabiertxof)]

Thanks su_v. This is the exactly problem I have when made this fix time ago.
I think this patch solve it. sorry for this long try :(.
I have more fixes in mind but is dificult to try because I couldent reproduce.

[su_v (suv-lp)]

Erratic behavior of the node tool when dragging a selected node of a path drawn with 'Ellipse' shape still reproducible with lp:inkscape/0.92.x r15075 + fix-bug-1621234.v5.patch; the width parameter is not updated initially (just after the path has been drawn) to reflect the actual scale of the pattern width (only after the original path has been edited, or the path has been de- and re-selected).

[su_v (suv-lp)]

On 2016-09-09 18:28 (+0200), Jabiertxof wrote:
> I have more fixes in mind but is dificult to try because I couldent
> reproduce.

Do you perhaps have a custom user default template installed which is
'px'-based? Then the erratic behavior is not exposed (because the width
of the 'Elllipse' shape is not scaled based on the document scale (AFAIU)).

In a new document based on the default template (SVG user unit
corresponds 1 mm), it is now consistently reproducible for me (if and
only if the 'Path Effects' dialog had been opened once in the current
session).

[su_v (suv-lp)]

Erratic node tool behavior also reproduced with patched trunk ( lp:inkscape r15110 + fix-bug-1621234.v5.patch ) on Ubuntu 14.04.5 LTS as described.

Conditions to reproduce consistently:
- new document based on default template (SVG user unit corresponds to 1 mm)
- 'Path Effects' editor opened first
- path drawn with bezier tool using 'Ellipse' shape
- node tool used to drag a selected node without de- and re-selecting the path just drawn with bezier tool in-between

Not further investigated: has current (last used) style any affect on the initial width of the 'Ellipse' shape? IIRC it does affect the powerstroke LPE used for the triangular shapes.

[Jabiertxof (jabiertxof)]

su_v finaly could reproduce it with new prefs, sorry for dont test this way.
Thanks so much for your help. Going to fix it now.

[Jabiertxof (jabiertxof)]

I hope this finaly fix. Thanks su_v.

[su_v (suv-lp)]

Based on a few quick tests, it seems to me that the latest patch (fix-bug-1621234.v6.patch) avoids the issue of the erratic behavior in the node tool by avoiding the one known situation which can trigger it: the initial width of the pattern ('Ellipse') is actually '1.00' (again). The consequence: drawing a path with 'Ellipse' as shape produces different output (width of the pattern) depending on the internal drawing scale of the current document (not a setting exposed to the user apart from predefined templates). Compare for example (with default prefs) the result of a path drawn in default template (mm-based A4 page) to the result of a path drawn in a new document based on the template 'default px' (px-based A4 page). IIRC the commit for bug #172137 (in r14778) introduced the (down-)scaling (to produce identical output in both cases) - possibly that was not intentional after all?

To me personally, the last patch looks more like a workaround which hides what seemed to me like a troublesome interaction between path effect parameters, their representation in the Path Effects dialog and the node tool context. Since I do not know whether that issue could be exposed in other scenarios (not tied to the bezier/pencil shape), it's up to you what kind of fix to commit.

[su_v (suv-lp)]

To summarize: 'fix-bug-1621234.v6.patch' fixes both symptoms:
- The width of the pattern is numerically editable again in the Path Effects dialog.
- The erratic node-editing as exposed by earlier patches does not reproduce in mm-based documents (e.g from default template).

It is unknown to me whether the patch fixes a possibly underlying issue that was exposed when node-editing the path for the first time with "mis-matching" path parameter values for the pattern width. There are no alternate 'steps to reproduce' known at this point, and the different initial widths of paths drawn with 'Ellipse' shapes depending on internal scale of current document does match behavior in earlier release and earlier trunk builds (though maybe not user expectations).

[Jabiertxof (jabiertxof)]

Hi su_v. I can change the beabiour to not change to 1 and retain 0.2.. in width if is better.
The problem are we are calling a transform method inside the LPE on creation.

I think I could change it if seems is better. Or maybe I could find another deeper solution, but I need to know the spected result to it.

Also think the problem, as you say, hapends in triangle in and triangle out powerstroke LPE. The tree actions need to have the same beabiour about scaling or not depends document scale.

Cheers, Jabier.

[Jabiertxof (jabiertxof)]

Hi. I think I find a deeper solution. Its also easy change the width from 0 to 2.xxx if seems better

[Jabiertxof (jabiertxof)]

Dont test last one improving it soon

[Jabiertxof (jabiertxof)]

This patch fix the issues in better way.
Also use currrent stroke width as base width in ellipse and triangle in/out.
I get a lot of problems with powerstroke -not related to this-, maybe go to it when finish this.

If get current stroke with is a problem I also add nest another patch without this.

[Jabiertxof (jabiertxof)]

This is simpler patch without geting current stroke with used

[su_v (suv-lp)]

On 2016-09-10 04:33 (+0200), Jabiertxof wrote:
> Also use currrent stroke width as base width in ellipse and triangle in/out.
<...>
> ** Patch added: "fix-bug-1621234.v8.patch"

Just a quick note: this must depend on the current tool's preference
setting whether to use its own style or the last used style (default has
been and still is to always use the pencil/bezier tool's own style - no
fill, black stroke with stroke-width 1 CSS px).

The current patch 'fix-bug-1621234.v8.patch AFAICT seems to ignore the
tool's setting when drawing with 'Ellipse' shape (always drawing with
width based on stroke of last used style).

I'll do more tests later (thanks for spending such an amount of time
into one detail of the LPE's application!).

[Jabiertxof (jabiertxof)]

Yes the "fix-bug-1621234.v8.patch" use the last used style like, I see it as improvement but maybe give some confusion.

With related second patch "fix-bug-1621234.v8.WhitoutScale.patch" its easy to start in a doc in "mm" at 0.2xx instead one if seems better than 1.

Thanks for the feedback!

[Jabiertxof (jabiertxof)]

This patch fix the triangle-in/out problem have if the current item has no stroke-width. Fixes it to the same width of ellipse shape.

[Jabiertxof (jabiertxof)]

This patch have all changes plus a little fix to powerstroke, render bad in some ocasions (usualy in triangle out from pen/cil tool but happends also manipulating powerstroke knots.

[Jabiertxof (jabiertxof)]

Finaly deprecate my code in "fix-bug-1621234.v8.patch"
https://bugs.launchpad.net/inkscape/+bug/1621234/comments/31.

two reasons:
1.- Maybe can be less ussable
2.- My plans to this LPE (and others) for 0.93 are allow set default values to a LPE so the user can, for example use while he want a 3,5 with in each pattern along path he create. This disturb totaly with the referenced code.

[Jabiertxof (jabiertxof)]

I have a working example about default LPE parameters in measure-line LPE https://code.launchpad.net/~inkscape.dev/inkscape/measure-line

[Jabiertxof (jabiertxof)]

This patch also fix bug #172137

[su_v (suv-lp)]

The issue originally reported here (width of a pattern for PaP can't be numerically adjusted) no longer reproduces with lp:inkscape/0.92.x + fix-bug-1621234.v11.FixScalePatternAlongPath.patch - the width parameter can be edited numerically in the Path Effects dialog and interactively on-canvas with the width handle. Changes are updated as expected.

AFAIU the patch does introduce other changes, for example with regard to the initial width / scale of paths drawn with a (pre-configured) shape using the bezier or pencil tool - these changes are actual outside the scope of this report (with latest patch, both powerstroke and PaP start with rather large default widths depending on the internal scale of the document), and it might be beneficial for the project if these changes see more and intensive testing (including feedback) by other users before a new release is made.

[Jabiertxof (jabiertxof)]

you think commit the changes and put a mail to devel and users mailing list a good idea? Or have another in mind when you write?

[Jabiertxof (jabiertxof)]

My idea is remove initial width / scale of paths drawn with a (pre-configured) shape. To get original 0.91+devel behabiour. I do it now.

[su_v (suv-lp)]

On 2016-09-11 11:14 (+0200), Jabiertxof wrote:
> you think commit the changes (...)

My recommendation would be to start with committing the changes to both
branches if you are confident about the stability and
backwards-compatibility of the code, and close this report as 'Fix
released', and bug #172137 as 'Fix Committed'.

> (...) and put a mail to devel and users mailing list a good idea?

<off-topic>
Since I personally have doubts that messages to the mailing list (devel)
will provide a lot of reliable and specific feedback (apart from the now
usual bike-shedding or diversion into other topics), I don't really ...
</off-topic>

> Or have another in mind when you write?

In hindsight, I probably just wanted to emphasize that discussions about
default shapes (pattern widths or powerstroke offsets) should be
followed up elsewhere (i.e. not in this report) - be it a specific new
report filed once the changes have been committed, or on the devel
mailing list. It was also meant to encourage testing by other members of
the bug team (or whoever followed the recent comments here and in
(related) bug #172137).

[Jabiertxof (jabiertxof)]

Hi su_v. Finaly I decide remove all code in the push not related to this (2) bugs.
Also I open 2 bugs more one about scaling of PaP and other with powerstroke fixes.

[Jabiertxof (jabiertxof)]

Fix commited:
trunk : 15111
0.92.x : 15076

[Jabiertxof (jabiertxof)]

commited last patch

[su_v (suv-lp)]

Just curious - is this compiler warning bogus?

[Jabiertxof (jabiertxof)]

I remove it. Maybe yes :( in bend from clipboard could happend in special cases of usages with last used and so on. Thanks for report it!

[Jabiertxof (jabiertxof)]

remove and commited.
trunk : 15112
0.92.x : 15077