Alan Horkan writes:
> I was thinking fo doing something similar for the python plugins (and
It was my intention to include python-fu as well. I must have missed
it because python-fu didn't get built in the tree I was using (it's
there now). I need to make an updated patch anyway, to include
placeholders, so I'll merge in the python scripts (there don't seem
to be very many of them) at the same time.
Nobody's commented on any of the other questions I asked in the bug,
like whether it would be a good idea to fold the short Glass Effects
menu into Light Effects, or moving Enhance up to where it's just
under Blur, or whether there's a reasonable place for Show Image
Structure since it's now the only item in Utils.
I'll go ahead and move Enhance since no one objected; maybe I'll
try to come up with some place to stick Show Image Structure.
(The bug is http://bugzilla.gnome.org/show_bug.cgi?id=116145 if
anyone wants to comment there or read the questions in more detail.)
> making sure to add ellipses where needed). However some of the python
> plugins duplicate existing functionality so putting two Clothify plugins
> beside each other would only confuse users. I see Akkanna tackled this by
> marking the Script-Fu unsharp as "Unsharp 2" but if people have idea on
> how to tackle this duplication of functionality I would be interested to
I'd be interested too. I don't like "Unsharp Mask 2" but strings
like "Unsharp Mask (script-fu)" are likely to make the menus too
long. Anyone have a better idea?
Joao S. O. Bueno Calligaris writes:
> People suggested that an icon before menu entries would cause to much
> hassle to the UI - and I agree.
Probably. It would be a nice idea but probably isn't worthwhile if
it doesn't plug in easily to the current menu code.
I do like the idea of being able to find out where a particular
menu item comes from.
> I suggested them that right-clicking
> on a menu item would bring some information about it. (Like: the
> package where it came from, what language it is written in, and maybe
> even accept a new shortcut for that item, without having to enable
> "dynamic shortcuts")
The problem with that is that many people still use right-click to
get the menus (you have to, if you want tear-offs, so I find I get
in the habit of using right-click most of the time instead of left
clicking in the menubar), and once I'm in a context menu which I
brought up by right-click, I expect right-click to continue to work
to invoke submenus and menu items. If that changed and suddenly
right-click did something else, and probably dismissed the menu at
the same time, it would take quite a while to relearn those habits
(and would make gimp's context menus inconsistent with most other apps).
I could see using a modifier key, e.g. control-click on a menu item,
or even mouse over a menu item and hit some key (f12 for help? ctrl-i
for info?) Except of course then you couldn't rebind that key any
more as a keyboard shortcut, so that's probably not a good idea either.
And neither a modifier-click nor a help key over the menu is very
discoverable. Tooltips would be discoverable, but they'd get in the
way as you explore the menu system.
...Akkana
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
