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 meantime.) Rockwalrus _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer