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

[programmer_ceds <forums gimpusers com>]

> 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: https://bugzilla.gnome.org/show_bug.cgi?id=708124 
> "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.

Thanks for the explanation.

-- 
programmer_ceds (via www.gimpusers.com/forums)