Re: [Gimp-user] Bug in "arrow" plugin, possible bug with tear-off menus

On 12/21/2016 06:58 AM, programmer_ceds wrote:
Thanks for the update. There would appear to be something odd with Paths in
V2.8.16 at least. The documentation says that the "eye" icon (to the left of the
"chain" icon and the preview) in the Paths dialog should show an open eye if the
path is visible - for me this icon is blank after I have defined a path.
Clicking on this icon after using the arrow script causes the path to reappear
on the image but in orange/red rather than the normal white - perhaps someone
could try this using V2.9 - if it still behaves the same way (the path isn't
shown after the Undo of the arrow script) then it would be worth filing a bug
report. If the path is shown in V2.9 then I would suggest ignoring the problem.
Re-running the arrow script after the Undo still uses the path even though it
isn't visible so for me it isn't a big issue.

Yes, definitely a minor bug in the Paths dialog -- has nothing to do with the arrow.scm script:

1) The eye icons aren't on by default. Probably an intentional feature (don't want lots of paths cluttering the image). 2) The selected path is shown in red and all others in blue for paths whose eye icon is turned on. This is regardless of whether the paths tool is active. 3) The bug: If the paths tool has been activated after using a different tool, the selected path in the paths dialog is not editable/stroke-able (nor displayed unless its eye icon is on) until a new path is created, either by clicking a first point in the image, or using "right-click -> New Path..." in the paths dialog. After that, all paths behave correctly (display/edit/stroke) until the paths tool is exited.

*** UPDATE ***
Just now found it: "Paths should be visible by default", originally from 2013 but see comments #13 through #17 from October of this year. Instead of creating a new path when re-entering the paths tool you can double-click on any path's "mini-preview" in the paths dialog -- it becomes displayed/editable/stroke-able and then selecting paths in the dialog works as it should. I agree with comment #16:

"So yes that feature is completely non-discoverable, and this is why I think it is not good user experience. For most people, the only way possible to edit an existing path seems to be to create a new one (even if you don't need it) first, which is absurd. Double-click is the way out of it, but nobody knows about it."

So this explains why "undo" after using arrow.scm with "Delete path after arrow was drawn?" turned on doesn't show the path, and the very non-intuitive workflow to get around it.

markrubn yahoo com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]