On 6/22/05, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
> Leon Brooks <[EMAIL PROTECTED] > writes:
> > Could a language-related mini-icon (16x16 or smaller) against each
> > menu entry help?
> The idea of the menu reorganization is to hide the language from the
> user because the user shouldn't have to care what language a filter is
> written in. Adding a language specific icon is contradicting this
> effort. 

I can't speak for anyone else who is working on menu reorginization,
but my personal goal is to restructure the menus so that it is easier
to find things.  Putting everything in the same categories regardless
of implementation flows naturally from this desire, since you look for
things by functionality, and because searching four menus in different
locations is more cumbersome.

It is important not to lose the forest for the trees.  One result of
moving functionality out of implementation-specific menus into a
common group is that information about implementation is less
prominant, but it would be a serious mistake to conclude from that
that this side effect is a goal.

> There will always be the plug-in browser if someone wants to  find out more 
> about a
> plug-in / script.

I'm not going to say that there isn't a place for the plug-in browser,
but this is not the place for it.  There are very legitimate reasons
that everyday users need to be aware of how a menu item is
implemented.  Some of these reasons are differences we can paper over
or eliminate, such as the fact that "repeat" repeats the last non-core
menu item ran, not the last run menu item.  Some issues, such as
knowing which bindings need to be installed to run your favorite
script, cannot.  There are several more examples I could list for both
categories, but I will be brief, since you are intellegent enough to
come up with them by yourself.

Since there are good reasons that users should be familiar with how
each menu item is implemented, it needs to be information that is well
presented.  Having such information unobtrusively placed in the UI is
the only way this can be achieved.  It is simply not reasonable to
bury this information in the plug-in browser, where the user has to
wade through irrelevant and likely-to-be uninteresting information for
every single menu entry.

For menu items that pop up dialogs, some ui element in the dialog
would be a good location; perl-fu already does this.  However, there
are some plug-ins, like Gradient Map, that don't show a dialog, so
unless you want to show a dialog like this:

--[Gradient Map]-----------------
| Gradient Map is written in C. |
| Since it's a plug-in you can  |
| use the repeat command to     |
| run it again.                 |
|                          [Ok] |

the most reasonable place to stick that info is in an icon in the menu.

Futhermore, the fact that this particular suggestion -- icons by the
menu items -- has been made by and most likely independantly thought
up by several people should be enough in of itself to show that there
is some merit to it.

> We should try to improve this browser instead of cluttering the menus with 
> such icons.

I don't think that adding such icons would be so bad, since after all,
there are icons in other spots in the menus already.  Even if doing so
did make the menus a bit less attractive, the added useful information
would more than balance it out.  Our goal is to have a program that is
useful and usable, not one that makes the centerfold of
Awesome-Looking Programs Monthly.  (Of course, it would be excellent
if the editors of said magazine used GIMP to edit their content, and
we don't want them to barf too much over looking at it in the

Gimp-developer mailing list

Reply via email to