Bug in "arrow" plugin, possible bug with tear-off menus
This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Bug in "arrow" plugin, possible bug with tear-off menus
After 13+ years I let my subscription to gimp-user-list lapse due to excessive bounces (don't know why that was happening). I wasn't following it too much anymore. So of course a month later I have to do some Gimping, run into problems, and need to re-subscribe. Teaches me a lesson. ;)
The "arrow.scm" plugin at http://registry.gimp.org/node/20269 doesn't work under 2.8.16 -- setting the stroke width has no effect (and it doesn't use the global brush width, either). I hacked up a fix: It looks like gimp-context-set-brush-size is now required instead of or in addition to gimp-brush-set-radius. The script hasn't been touched since 2009, and the last comment on the web page is 2013. What's the protocol for submitting a patch, or should I just keep a working copy for myself?
Problem #2: Tear-off menus (2.8.16 again) don't work, at least in my environment (Linux, X11, FVWM window manager). For example, right-click-and-hold in an image window, move down to "Colors >", move across to the submenu and down to "Invert" and release -- that works. But right-click-and-hold, move down to "Colors >", move across to the top "-----" line and release to create a tear-off menu. Then in that new "Colors" menu/window, click on "Invert" and nothing happens. (Actually, something does -- the message area in the lower right corner of the image window changes to say "Invert the colors", but the image doesn't change.) Same (no)thing with menu items that should pop up a dialog window, like "Levels...". But doing a deeper submenu from the tear-off menu, like "Map >" and then "Alien map..." from there does work.
I couldn't find this on Bugzilla. Can anyone else recreate it? I'm guessing it hasn't shown up because everyone's on Windows or some fancy Linux "desktop environment" and/or does the thing where you dock all the menus/windows/dialogs into the main image window (I don't know how to do that, nor why I'd want to).
Thanks for any suggestions. Also for keeping gimp-user-list alive. Were there lots of posts about changing "File -> Save As..." back to allow saving to JPEG/PNG/etc in addition to XCF instead of having to use "File -> Export" while I was gone? ;)
MARK markrubn@yahoo.com
- postings
- 121
Bug in "arrow" plugin, possible bug with tear-off menus
After 13+ years I let my subscription to gimp-user-list lapse due to excessive bounces (don't know why that was happening). I wasn't following it too much anymore. So of course a month later I have to do some Gimping, run into problems, and need to re-subscribe. Teaches me a
lesson. ;)The "arrow.scm" plugin at http://registry.gimp.org/node/20269 doesn't work under 2.8.16 -- setting the stroke width has no effect (and it doesn't use the global brush width, either). I hacked up a fix: It looks
like gimp-context-set-brush-size is now required instead of or in addition to gimp-brush-set-radius. The script hasn't been touched since
2009, and the last comment on the web page is 2013. What's the protocol
for submitting a patch, or should I just keep a working copy for myself?Problem #2: Tear-off menus (2.8.16 again) don't work, at least in my environment (Linux, X11, FVWM window manager). For example, right-click-and-hold in an image window, move down to "Colors >", move across to the submenu and down to "Invert" and release -- that works. But right-click-and-hold, move down to "Colors >", move across to the top "-----" line and release to create a tear-off menu. Then in that new
"Colors" menu/window, click on "Invert" and nothing happens. (Actually,
something does -- the message area in the lower right corner of the image window changes to say "Invert the colors", but the image doesn't change.) Same (no)thing with menu items that should pop up a dialog window, like "Levels...". But doing a deeper submenu from the tear-off menu, like "Map >" and then "Alien map..." from there does work.I couldn't find this on Bugzilla. Can anyone else recreate it? I'm guessing it hasn't shown up because everyone's on Windows or some fancy
Linux "desktop environment" and/or does the thing where you dock all the
menus/windows/dialogs into the main image window (I don't know how to do
that, nor why I'd want to).Thanks for any suggestions. Also for keeping gimp-user-list alive. Were
there lots of posts about changing "File -> Save As..." back to allow saving to JPEG/PNG/etc in addition to XCF instead of having to use "File
-> Export" while I was gone? ;)
I have made a number of changes to this script over the years, the most recent, in 2014, being to allow curved arrows. I added an entry to the registry with a note to say that I couldn't upload the script but posted a link to it instead. There were a number of other changes that I had made to the script before that but I'm not sure whether or not they address the brush issue that you have. perhaps you could try my version of the script. If necessary we could amalgamate the changes to get a script that corrects a number of issues with the original script, draws curved arrows and solves your problem.
I don't know of a site that hosts GIMP scripts whilst the registry is unavailable but I am happy to replace the zip file on my site with an updated one for the time being.
The latest version of the script:
http://www.programmer97.talktalk.net/Files/arrow.zip
The GIMP registry page for the version of the script that includes curved arrows:
Bug in "arrow" plugin, possible bug with tear-off menus
On 12/19/2016 02:20 AM, mark_at_yahoo via gimp-user-list wrote:
Problem #2: Tear-off menus (2.8.16 again) don't work, at least in my environment (Linux, X11, FVWM window manager). For example, right-click-and-hold in an image window, move down to "Colors >", move across to the submenu and down to "Invert" and release -- that works. But right-click-and-hold, move down to "Colors >", move across to the top "-----" line and release to create a tear-off menu. Then in that new "Colors" menu/window, click on "Invert" and nothing happens. (Actually, something does -- the message area in the lower right corner of the image window changes to say "Invert the colors", but the image doesn't change.) Same (no)thing with menu items that should pop up a dialog window, like "Levels...". But doing a deeper submenu from the tear-off menu, like "Map >" and then "Alien map..." from there does work.
I couldn't find this on Bugzilla. Can anyone else recreate it?
To duplicate this behavior, use the tear off menu function on Linux. That's it: As far as I know, it's the same with all distros and window managers: I have seen it on Ubuntu and Mint (both Debian based) and under Gnome, Cinnamon and XFCE4. I think it's a GTK+ thing but don't quote me on that.
Work-around: Left click the menu item on the torn-off menu to select it, then press the space bar on your keyboard to "make it work."
Why/how the space bar does that is way above my pay grade. It's been that way for so long that I don't remember if I stumbled on the space bar trick by myself, found it by searching the network or read it here. But I do recall posting something about it, and at least one "real" expert replying to the effect that she had the same problem and did not know there was a work around.
:o)
Bug in "arrow" plugin, possible bug with tear-off menus
On 12/19/2016 08:14 AM, Steve Kinney wrote:
To duplicate this behavior, use the tear off menu function on Linux. That's it: As far as I know, it's the same with all distros and window managers: I have seen it on Ubuntu and Mint (both Debian based) and under Gnome, Cinnamon and XFCE4. I think it's a GTK+ thing but don't quote me on that.
Work-around: Left click the menu item on the torn-off menu to select it, then press the space bar on your keyboard to "make it work."
Thanks for the work-around! That makes it clumsily, marginally better than going through two-level pulldowns, usable.
So this is a longstanding bug? I vaguely remember doing it sans-workaround "way back when" == unknown version. It was an important part of my workflow. Getting more convinced that nobody uses this part of the UI anymore. I wonder if it's worth filing on Bugzilla or if it'll be a "will not fix", especially if it falls in the cracks between GIMP and gtk (can't even find GTK+ or generic "gtk" in the Bugzilla product list, just specific sub-projects).
Thanks again for the quick and helpful reply. The gimp-user-list: Still coming through with mission-critical information after all these years!
Bug in "arrow" plugin, possible bug with tear-off menus
On 12/19/2016 09:04 AM, mark_at_yahoo via gimp-user-list wrote:
So this is a longstanding bug? I vaguely remember doing it sans-workaround "way back when" == unknown version.
Late-breaking news: I went into my personal, "posts I found interesting enough to save" archives of this list and found a 2004 notice about removing tear-off menu configuration from the preferences dialog. I had already looked there in 2.8 and there was nothing.
I just now experimented and found that adding "(tearoff-menus no)" to my ~/.gimp-2.8/gimprc *does* turn them off; the "------" line at the top of the secondary menu no longer appears. Setting it back to "yes" re-enables them, as of course does leaving out the tag completely. The tag isn't in any of the system-wide configuration files (/usr/share/gimp/2.0/themes/*/gtkrc on my distro) so I'm guessing the compiled-in default is "yes".
So it's still in the codebase, just probably dusty and untouched for 10+ years.
Sorry for the spam -- likely nobody's interested in any of this -- but thanks again to Steve for helping me out.
Bug in "arrow" plugin, possible bug with tear-off menus
On 12/19/2016 03:01 AM, programmer_ceds wrote:
I have made a number of changes to this script over the years, the most recent, in 2014, being to allow curved arrows. I added an entry to the registry with a note to say that I couldn't upload the script but posted a link to it instead. There were a number of other changes that I had made to the script before that but I'm not sure whether or not they address the brush issue that you have. perhaps you could try my version of the script. If necessary we could amalgamate the changes to get a script that corrects a number of issues with the original script, draws curved arrows and solves your problem.
I don't know of a site that hosts GIMP scripts whilst the registry is unavailable but I am happy to replace the zip file on my site with an updated one for the time being.
The latest version of the script:
http://www.programmer97.talktalk.net/Files/arrow.zip
The GIMP registry page for the version of the script that includes curved arrows:
Thanks, programmer_ceds. Yes, I saw your page on the registry but didn't follow the link to the actual script. My bad.
(BTW, I got your post to the list hours after my previous replies. This had been happening for the last year or two I was on the list -- I'd get posts out of order, and delayed up to a day or more. Maybe it's related to why the mailman server was getting bounces from me and kicked me off the list.)
I just now tried your script and it works. Looking at the code, you did change gimp-brush-set-radius to gimp-context-set-brush-size (which is the only thing I did), plus of course much more to support curves. Nice work, all of it.
I think I saw one small problem in that if the path has more than two points and "double headed arrows" is turned on the script uses the path's first and second points instead of first and last like the popup warning says (nice touch having the popup). And if you're in the mood for coding I'd suggest adding another toggle to change between absolute and relative values instead of using negative numbers for relative as per the original script. But it's not that important.
If the registry ever gets working again I think yours should replace the original because it's a complete superset of the that one's functionality. Thanks again for your work.
MARK markrubn@yahoo.com
- postings
- 121
Bug in "arrow" plugin, possible bug with tear-off menus
Thanks, programmer_ceds. Yes, I saw your page on the registry but didn't follow the link to the actual script. My bad.
(BTW, I got your post to the list hours after my previous replies. This
had been happening for the last year or two I was on the list -- I'd get
posts out of order, and delayed up to a day or more. Maybe it's related
to why the mailman server was getting bounces from me and kicked me off
the list.)I just now tried your script and it works. Looking at the code, you did
change gimp-brush-set-radius to gimp-context-set-brush-size (which is the only thing I did), plus of course much more to support curves. Nice
work, all of it.I think I saw one small problem in that if the path has more than two points and "double headed arrows" is turned on the script uses the path's first and second points instead of first and last like the popup
warning says (nice touch having the popup). And if you're in the mood for coding I'd suggest adding another toggle to change between absolute
and relative values instead of using negative numbers for relative as per the original script. But it's not that important.If the registry ever gets working again I think yours should replace the
original because it's a complete superset of the that one's functionality. Thanks again for your work.
The script was really only intended to work with a path of 2 points only but I will look at modifying it to place the second arrow at the final point of the curve.
Having just checked, there is also an issue if a single arrow head is drawn based on the last point of a path with more than two points - the centre of the arrow doesn't lie along the final segment of the path. The easy approach would be to only allow the script to work on paths with two points but I'll think about it.
Regarding the relative/absolute values - there are two of the controls where this would have to be done if they are to operate independently and give the greatest flexibility. Again I'll think about this.
Bug in "arrow" plugin, possible bug with tear-off menus
On 12/19/2016 12:01:12 PM, programmer_ceds wrote:
I have made a number of changes to this script over the years, the most recent,
in 2014, being to allow curved arrows. I added an entry to the registry with a
note to say that I couldn't upload the script but posted a link to it instead.
There were a number of other changes that I had made to the script before that
but I'm not sure whether or not they address the brush issue that you have.
perhaps you could try my version of the script. If necessary we could amalgamate
the changes to get a script that corrects a number of issues with the original
script, draws curved arrows and solves your problem.
I had to apply the patch below to make your script run under Gimp 2.9. Are these patches OK ?
Thanks, Helmut
--- arrow.scm.ORIG 2014-09-16 11:21:14.000000000 +0200
+++ ../arrow.scm 2015-12-11 11:16:30.810268551 +0100
@@ -119,7 +119,7 @@
(aset points 2 theLeftWingEndPointX) (aset points 3
theLeftWingEndPointY)
(aset points 4 theMiddleWingEndPointX) (aset points 5
theMiddleWingEndPointY)
(aset points 6 theRightWingEndPointX) (aset points 7
theRightWingEndPointY)
- (gimp-free-select image 8 points CHANNEL-OP-REPLACE TRUE
FALSE 0)
+ (gimp-image-select-polygon image CHANNEL-OP-REPLACE 8
points)
(gimp-edit-bucket-fill drawable FG-BUCKET-FILL
NORMAL-MODE 100 0 FALSE 0 0)
(gimp-selection-none image)
))
@@ -312,7 +312,7 @@
(set! num_points (* num_points 2))
(set! num_points (+ num_points 6))
- (gimp-free-select image num_points
in_fill_points CHANNEL-OP-REPLACE TRUE FALSE 0)
+ (gimp-image-select-polygon image
CHANNEL-OP-REPLACE num_points in_fill_points)
(gimp-edit-bucket-fill drawable
FG-BUCKET-FILL NORMAL-MODE 100 0 FALSE 0 0)
(gimp-selection-none image)
) ; end -begin
@@ -450,7 +450,7 @@
(car
(gimp-image-height image))
(+ 1 (* 2
(car (gimp-image-base-type image))))
"Arrow" 100
NORMAL-MODE )))
- (gimp-image-add-layer image drawable 0)
+ (gimp-image-insert-layer image drawable 0 0)
; set new layer completely transparent
(gimp-layer-add-mask drawable (car
(gimp-layer-create-mask drawable ADD-BLACK-MASK)))
(gimp-layer-remove-mask drawable MASK-APPLY)
- postings
- 121
Bug in "arrow" plugin, possible bug with tear-off menus
I had to apply the patch below to make your script run under Gimp 2.9. Are these patches OK ?
Thanks, Helmut
--- arrow.scm.ORIG 2014-09-16 11:21:14.000000000 +0200 +++ ../arrow.scm 2015-12-11 11:16:30.810268551 +0100 @@ -119,7 +119,7 @@
(aset points 2 theLeftWingEndPointX) (aset points 3 theLeftWingEndPointY)
(aset points 4 theMiddleWingEndPointX) (aset points 5 theMiddleWingEndPointY)
(aset points 6 theRightWingEndPointX) (aset points 7 theRightWingEndPointY)
- (gimp-free-select image 8 points CHANNEL-OP-REPLACE TRUE FALSE 0)
+ (gimp-image-select-polygon image CHANNEL-OP-REPLACE 8 points)
(gimp-edit-bucket-fill drawable FG-BUCKET-FILL NORMAL-MODE 100 0 FALSE 0 0)
(gimp-selection-none image) ))
@@ -312,7 +312,7 @@(set! num_points (* num_points 2)) (set! num_points (+ num_points 6)) - (gimp-free-select image num_points in_fill_points CHANNEL-OP-REPLACE TRUE FALSE 0) + (gimp-image-select-polygon image CHANNEL-OP-REPLACE num_points in_fill_points) (gimp-edit-bucket-fill drawable FG-BUCKET-FILL NORMAL-MODE 100 0 FALSE 0 0) (gimp-selection-none image)
) ; end -begin
@@ -450,7 +450,7 @@
(car (gimp-image-height image))
(+ 1 (* 2
(car (gimp-image-base-type image)))) "Arrow"
100
NORMAL-MODE )))
- (gimp-image-add-layer image drawable 0) + (gimp-image-insert-layer image drawable 0 0) ; set new layer completely transparent (gimp-layer-add-mask drawable (car (gimp-layer-create-mask drawable ADD-BLACK-MASK))) (gimp-layer-remove-mask drawable MASK-APPLY)
Hi Mark,
I modified the script last night to correct the drawing of arrow heads at the end of paths with more than two points. I also included the suggestion about only using positive numbers.
I still have to tidy the changes a bit and I will do this later and update the zip file then.
Hi Helmut
I had been wondering whether the scripts that I have written would still work on V2.9/2.10, thanks for providing the patches. To make life easier for me (I use Windows) is it possible that you could post the complete version of the script as you have edited it (or provide a link so that I can download it) - I can then use a file comparison program to compare it with the original unedited version and incorporate the differences into my newly modified version - this should be easiest way of transferring the changes without introducing errors (alternatively is there a simple unified diff inclusion program for W7?). If the changes required for V2.9 mean that the script will not work under V2.8 I will add conditional code so that it will function under either version.
- postings
- 121
Bug in "arrow" plugin, possible bug with tear-off menus
Hi Mark,
I modified the script last night to correct the drawing of arrow heads at the end of paths with more than two points. I also included the suggestion about only using positive numbers.
I still have to tidy the changes a bit and I will do this later and update the zip file then.
Hi Helmut
I had been wondering whether the scripts that I have written would still work on V2.9/2.10, thanks for providing the patches. To make life easier for me (I use Windows) is it possible that you could post the complete version of the script as you have edited it (or provide a link so that I can download it) - I can then use a file comparison program to compare it with the original unedited version and incorporate the differences into my newly modified version - this should be easiest way of transferring the changes without introducing errors (alternatively is there a simple unified diff inclusion program for W7?). If the changes required for V2.9 mean that the script will not work under V2.8 I will add conditional code so that it will function under either version.
Hi Mark and Helmut,
I have made the following changes:
Corrected the drawing of arrow heads at the end of paths that have more than 2 points
Added extra controls to determine whether the wing length and brush thickness are related to the path length or in absolute pixels. This is instead of using negative numbers for relative settings and positive numbers for absolute pixel values.
Added patches, supplied by Helmut, to allow the script to work in GIMP V2.9/V2.10
Removed previous edit comments and commented out code
The warning about paths with more than 2 points is now only given once following an activation of GIMP or a refresh of the Script-Fu scripts
Swapped the up/down cursor key actions with the page up/down actions for the LoW and BT value fields (the page keys now increment/decrement by 10 and the up/down keys by 1)
I copied and pasted the changes from the diff file noted above so hopefully I have done this correctly - could you check on V2.9 for me please Helmut. The other good news is that the modified code works fine in V2.8.16 (I made sure that all 3 changes were executed by the script)
The revised version is at the same link as before:
http://www.programmer97.talktalk.net/Files/arrow.zip
Please let me know if there are any problems.
Bug in "arrow" plugin, possible bug with tear-off menus
On 12/20/2016 08:11 AM, programmer_ceds wrote:
Hi Mark and Helmut,
I have made the following changes:
Corrected the drawing of arrow heads at the end of paths that have more than 2 points
Thanks!
Added extra controls to determine whether the wing length and brush thickness are related to the path
length or in absolute pixels. This is instead of using negative numbers for relative settings and
positive numbers for absolute pixel values.
Perfect! The old way was usable, but not user-friendly to non-programmers. :)
The warning about paths with more than 2 points is now only given once following an activation of GIMP
or a refresh of the Script-Fu scripts
Very nice!
Please let me know if there are any problems.
Looks good for me here on 2.8.16/Linux.
I thought I had a case where turning on "Curved arrow wings?" worked on a highly curved, multiple-point path with the last point's tangent handles moved around, but when that toggle was off the non-curved end arrow was at a funny orientation. But I couldn't recreate it later, so maybe it was user error. If it shows up again I'll try to capture it and send you an .xcf file.
Also, I like to run the script with "Use new layer for arrow?" turned off, and "Delete path after arrow was drawn?" turned on. That works perfectly (the path is removed from the Paths dialog box). But if I don't like the results and do Edit -> Undo Arrow, the arrow is removed from the image and the path returns to the Path dialog as the selected path, but the it (points, handles, path) isn't visible in the image window, and "Selection From Path" and "Stroke Path" are grayed-out/inactive in the Toolbox dialog. Even selecting other paths doesn't make them visible or "stroke-able". At that point creating a new path behaves normally, and the Paths dialog can then be used to switch back and forth between any of the paths and they become visible/editable/stroke-able as they are selected. It's not that big a problem, and the original script does the same thing. Maybe some problem with gimp-image-undo-group-start/-end, or a bug in the internal implementation of those methods.
Sorry for too many details, but I thought I'd describe what I found in my testing. Once again, thanks for all the work you've put into this very useful script.
MARK markrubn@yahoo.com
Bug in "arrow" plugin, possible bug with tear-off menus
On 12/20/2016 05:11:25 PM, programmer_ceds wrote:
The revised version is at the same link as before:
http://www.programmer97.talktalk.net/Files/arrow.zip
Please let me know if there are any problems.
Many thanks, it works just fine on GIMP (GIT-version) on Linux, Helmut
- postings
- 121
Bug in "arrow" plugin, possible bug with tear-off menus
Also, I like to run the script with "Use new layer for arrow?" turned off, and "Delete path after arrow was drawn?" turned on. That works perfectly (the path is removed from the Paths dialog box). But if I don't like the results and do Edit -> Undo Arrow, the arrow is removed from the image and the path returns to the Path dialog as the selected path, but the it (points, handles, path) isn't visible in the image window, and "Selection From Path" and "Stroke Path" are grayed-out/inactive in the Toolbox dialog. Even selecting other paths doesn't make them visible or "stroke-able". At that point creating a new
path behaves normally, and the Paths dialog can then be used to switch back and forth between any of the paths and they become visible/editable/stroke-able as they are selected. It's not that big a problem, and the original script does the same thing. Maybe some problem
with gimp-image-undo-group-start/-end, or a bug in the internal implementation of those methods.
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.
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: 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.
MARK markrubn@yahoo.com
- postings
- 121
Bug in "arrow" plugin, possible bug with tear-off menus
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.
Bug in "arrow" plugin, possible bug with tear-off menus
On 12/19/2016 12:31 PM, mark_at_yahoo via gimp-user-list wrote:
Sorry for the spam -- likely nobody's interested in any of this -- but thanks again to Steve for helping me out.
I think it's interesting. I don't use tear-off menus /very/ often, but when I do they make life a whole lot easier: Generally speaking, when you need to do the same operations a whole lot of times per image or process, if there's not a keyboard shortcut you can "tear off" a menu that's buried three deep in the hierarchy and leave it open.
If nobody's interested in them, it's because tear off menus have not "just worked" for so long that nobody knows about them.
:o)