GNOME Bugzilla – Bug 116145
UI clarity - re-organize scripts and plug-ins in the menus
Last modified: 2006-08-15 16:57:02 UTC
Situation: Tools are currently split obscurely according to the method used to program them - ie Script Fu, Tools, Filter and Xtns. Problem: This is confusing to end-users, who do not care that the developer programmed in script-fu, for example. GIMP has a steep learning curve, and this can't help. Possible solution: A unified method of accessing all of GIMP's functions - organized by, for example, -color : with 'color picker', 'map gradient' etc -render : all of the render options, both scripted and not -text : the usual text tool accesible with the right mouse button, plus all of the text functions buried under Xtns.
This has been discussed several times on the gimp-developer list. I thought this had been reported earlier, but I cannot find a related bug report. So I will confirm this one. Yes, it would be better to have all filters in the Filters menu, regardless of the language they are written in. For version 1.0 of the GIMP, an argument against doing so was that some operations like Undo behaved very differently between scripts and plug-ins, so it was better to have them in different menus so that the user has a better chance to know what to expect from each. But most of these differences have been resolved in version 1.2 and it would make sense to re-organize all menus for version 1.4 or 2.0.
Can someone please rename this bug-report. The summary is confusing, to say the least. Tools have a special meaning in GIMP and it is not tools that you are talking about. The term accessibility also has a special meaning in the GUI context which is probably not what you mean here. I have been asking for a volunteer to reorganize the menus for 2.0 for several years now. Noone wanted to do it, I would say it's too late now.
We cannot simply merge tools and plug-ins since they are too different and it makes sense to give the user a chance to differentiate them. If we can get plug-ins and scripts behave identically (mainly with respect to Undo), the Filters and Script-Fu menus should probably me merged. The Xtns menu has a special meaning as well which should IMHO stay. It contains only operations that do not work on a particular image. They should thus not be in the image menu.
You forgot to mention the Python-Fu and the, yet to come in 1.3.x, Perl menu... ;-) I agree. Having all plug-ins/Script-Fus/Python-Fus/etc in one menu (<Image>/Filters ?) would be ideal. I also agree with Sven that the tools should not be included in this menu, but should be kept in the <Image>/Tools/ menu. Maybe we could rename the Xtns menu? It's not a very intuitive name - but I can not think of a better one as of now (Maybe just spell it out?).
Indeed there's a script-fu within the Filters menu, namely Tileable Blur. There are IMO a few issues to address before doing this change that may even become separate bug reports (and indeed this can be a tracking bug for all of these): - When a script is executed, repeat/re-show last is not affected. I thought it was a bug of Tileable Blur before I noticed that it was a script; since it was a filter from the Filters menu, why couldn't I just repeat a filter? - "Undo" for scripts has no description of the actual action performed; the Undo History dialog just shows "script-fu" (and maybe python-fu in its case, I don't have it installed). This may confuse users who are not aware of what kind of filter they are applying. - Scripts are usually more fragile than C code; if a script breaks, which happens relatively often, it's very likely that Undo becomes unavailable because it was pushed but never popped. I'd say that a check for push-pop balance should be made at the end of every script, especially if it failed. I will write three separate reports if required.
Perhaps the solution to giving the user a chance to figure out what is a script and what is gimp native, so that they know what sort of undo they will get, is to put a little icon next to all of the scripted tools (something like a superman \S/ ). With regard to Xtns, what do you think about this- -'Web Browser' submenu to the 'Help' menu. -'Module Browser', 'DB Browser', 'Plugin Details' and 'Unit Editor' to a submenu in 'File' called 'Addons'. -'Xtns' being called 'Wizards' and containing all of the plugins that will create a new image (all those currently under 'Xtns'->'Script Fu') I know 'wizards' seems like a lame Microsoft Office sort of name, but I can't think of a better one.
Problem: > confusing to end-users, who do not care that the developer programmed in script-fu Implementation details should not be exposed to the user if possible. Same goes for the Dialogs menu, ideally you want to reorganise based on the funtionality or how they are used, the best example I can think of it that Undo History would be much better off if it was just after Undo and Redo (various other programs do this). (but that is a whole other bug report) >> Yes, it would be better to have all filters in the Filters menu, great we have agreement in principle. >>> ------- Additional Comments From sven@gimp.org 2003-06-30 14:09 ------- >>> respect to Undo), the Filters and Script-Fu menus should probably be merged. and a smaller more achievable shorter term goal! >>>> Maybe we could rename the Xtns menu? It's not a very intuitive name - IMNSHO Abbrvtns R almost always bad idea (IYKWIM). Extensions is a bit long in English, I wonder what other languages have done here. In user interface design you always have to leave plenty of space usually for languages like German. I would suggest Plugins or maybe Tools but the GIMP already uses those terms in a different way so they are probably not appropriate. but please do consider calling it Plugins anyway :) there are all 'added-on' that are or 'plugged in', the inherent difference between a script and a plugin is implementation details. ------- Additional Comments From Pedro Gimeno 2003-07-05 03:57 ------- >>>>> There are IMO a few issues to address before doing this change that are we so close to 1.4 or even 2.0 that we should wait? you have already said that there is a Script-Fu in the plugins menu. The various bugs you mention apply to scripts no matter where they are wouldn't it be better to make progress? I think you should probably file those seperate bug reports you suggested. ------- Additional Comments From oli 2003-07-05 09:15 ------- >>>>> With regard to Xtns, what do you think about this- >>>>> -'Web Browser' submenu to the 'Help' menu. Yes and maybe reduce the number of links to as little as one, or two. There will be old copies of the GIMP around long after some of those links get changed or broken. >>>>> I know 'wizards' seems like a lame Microsoft Office sort of name, but I dont think is lame but it already has an associated meaning so I would not recommend trying to use it to mean something else.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
The part of this bug report which deals with the webbrowser plug-in has been solved - see bug #119120. I still think we should come up with a better name and organisation for the <Toolbox>/Xtns menu - IMHO something along the lines of what oli suggested (2003-07-05 09:15) wouldn't be half bad: * The webbrowser plug-in has been replaced and it's menu entries relocated to the <Toolbox>/Help menu *'Module Browser', 'DB Browser', 'Plugin Details' and 'Unit Editor' could be moved to a submenu in <Toolbox>/File called 'Addons' or similar * The <Toolbox>/Xtns menu could then be renamed to 'Wizards' or similar and the 'Script-Fu' and 'Python-Fu' submenus could be merged (along with a clean-up of the categories) This change could be implemented before 2.0 - and we could target the merge of <Image>/Filters, <Image>/Script-Fu, <Image>/Python-Fu etc. for 2.2.
IMHO 'Module Browser', 'DB Browser', 'Plugin Details' and 'Unit Editor' are very well located in the Extensions menu. Definitely better than moving them to a File menu. I think the current Xtns menu is just perfect, no need to change it.
Beware too deep menues too. Things should be easily accessible, with few clicks. Instead of having everything under "Filters" menu, there should be several top level menus. These could include: "Image" - cropping, resizing and other such operations that affect the whole image canvas; note: color and transform are moved elsewhere, even though they may also affect image dimensions; since this is making the Image menu quite small, maybe layers menu should be made a submenu of this one? Image/Layers at least seems like the place where I would go looking for layer options, if it wasn't top level menu. - some items from current Edit menu should be moved here "Color" - mode: indexed/rgb24/.. - anything that is mostly meant for color operations - some filters in this menu may need to read surrounding pixels too (contrast enhancement filters in particular) "Transform" - mirror, rotate, whirl, .. (for image, layer or selection?) - anything that mostly changes image shape "Filter" - blur, mosaic and others that don't fall under the previous categories "Render" - generate new material, not by filtering existing image - lens flares, buttons and other such effects Basically, use common sense in deciding where a thing should go. Never base your selection on what resources the plugin needs or how it is implemented. For the script issue - [S] or [Py] could be appended to plugin name in the menu. Dialogs menu could be moved under View menu. Various alpha/transparency settings are quite problematic, but I guess they should go under "Color". Gimp should probably always use alpha internally and thus the "fill with fg color" and such options should be removed. Instead, the image would always be totally transparent when cleared and then the image canvas color (that affects how it is displayed and saving of it in non-alpha formats) should be changed. This needs some further work, but this should be a good base for someone to work on. There is quite a lot work to be done, as many filters need to be modified and deciding the final menu layout isn't too easy either. Hopefully we'll get the new menus for 3.0, whenever that may be released...
GIMP-2.2 (which is scheduled for this summer) is supposed to read all it's menus from one or more XML file(s). That should make it a lot easier to reconfigure the menus and to come up with a better default. This definitely doesn't have to wait for GIMP-3.0. It remains to be seen how well plug-ins will integrate with GtkAction-based menus.
Changing summary line to make this bug easier to find.
*** Bug 122657 has been marked as a duplicate of this bug. ***
And yet again, another chance to reorganize the menus has been ignored. Since there's no complete proposal and onbiously noone who feels responsible for this, the great menu reorganization will have to wait for the next release cycle.
It seems it's a lot easier to find people who complain about the current menu organization that people who are willing to do anything constructive to fix it. Not that that is completely surprising. :) Of course, I could rearrange everything the way I think best, but I was hoping to try to inspire other people to say something productive. Loosing the wiki for a while didn't help, of course. And that discussed but apparently never done word association test would have helped phenominally. But annoyingly, there are always more good things to do then time to do them in, I guess. Anyway, I still plan to have the Script-Fu menu items we talked about moved before we release 2.2.
Well, here's the thing: menu reorganization is a perfect example of the sort of task that full-democracy fails at. It cannot be done without leadership. The right approach is to appoint a committee of 2-3 volunteers, who will solicit suggestions, come up with a proposal, publish it on the mailing list, consider the feedback, come up with a revised proposal, and have Sven decide whether to accept it.
Nathan, you are certainly aware that September has passed by and that we are in tentative feature freeze now. I am only going to accept a handful of last-minute changes that have been discussed beforehand. This freeze has been announced for a while. I plan to to tell the translators that they can start working on i18n for 2.2 now. I'd say it is simply too late for further menu reorganizations.
Yeah, I know that gimp is your toy, and so no one should be so presumptious as to think that it's not the height of perfection. I'm too sick of your crappy attitude towards other people who want to help to care any more. It's true that we've "discussed" this "beforehand", and that it's a fairly minor change involving only a handful of scripts, and there won't be any further complications, and that it would be benificial to our users to have things more consistant and discoverable, but obviously I need to do more "research" before I'm compentant to talk about a program that I've spent more than a solid man-year working on, often for no personal benefit. You seem to have a contempt for anyone who doesn't kowtow to your every opinion and whim. That is not leadership; it is meglomania. Your contempt for the average user is obvious: you see users as lazy and ignorant, and anything to make GIMP easier to use, unless it involves some cool programming gizmo, is almost always rejected or made low-priority to you. Somehow changing a few strings is "simply too late" because you were planning to tell the translators sometime in the future that they can start translating for 2.2? Don't give me that garbage! How is it that you can't tell them that the strings in that particular menu location are going to be moved? I have been more than patient with your lack of social skills, but there is only so much that a person can take. There was a time when everyone who wanted to make a contribution to GIMP was valued and accomadated; that time is no longer. I'm ashamed to be associated with a project that treats people so poorly.
It's not just "changing a few strings". It would mean a lot of effort for the translators, doc writers and countless independent tutorial writers all around the globe to adjust to a new menu structure. And think about the users who are lost with tutorials and docs and mails and posts spread all over the Internet. Even the Image/Layer split happening from 1.2 to 2.0 has confused a lot of users... IMO, Bill is right with his remark about such things not working in a democracy. Wouldn't be much of a problem since there were never too many contributors to the menu structure wiki page. This is part of the problem - it isn't widely known that there is a menu reoganization taking place. Maybe someone who feels responsible should advertize it on the usual channels?
There has been a lot of time to improve the menus. This time has not been used. So this issue (like many many others) will have to wait for the next development cycle. We need to freeze the strings to give translators a chance to finish their job for 2.2 and we need to freeze the UI to give the gimp-help people a chace to get the help files into shape for 2.2. This has to happen at some point. This is nothing about me and GIMP being my toy, it is about managing a software project and trying to stick to the schedule that has been setup before. We all know that we are more than a full month behind our schedule already. Nathan, please stop abusing Bugzilla for your personal flames. I am very much disappointed about the fact that the script changes aren't ready for 2.2. Alan has put a siginificant amount of work into improving the scripts. You volunteered to review the changes and to get them into CVS. You failed to do that in time and now you are blaming me for it? It's a shame that these improvements are not yet ready for 2.2 and I hoped that you would have had a patch ready that we could still apply. But it seems you prefer to waste your time with uneducated comments and sinless rants :(
*** Bug 158150 has been marked as a duplicate of this bug. ***
Look here: http://bugzilla.gnome.org/bug_status.html#priority Bug priority "High" includes "and more minor bugs that are frequently reported". There are now multiple duplicates. Comment #1 says that this problem has been "discussed several times on the gimp-developer list". Thus, the priority should be set to "High" now.
What would that change? If you want to push this, then please join the ongoing effort and help out the people working on menu reorganization so that we have a well-done proposal for a new menu structure early in the next development cycle.
Setting the priority to "High" as indicated by the GNOME Bugzilla documentation should serve to remind people of, well, the priority. The field has a documented purpose; it is incorectly set for this bug. The field should have been changed with comment #1, which indicated that this bug has been reported multiple times before. Since then, two duplicates have been filed. If priority is an unused field, then the GNOME Bugzilla documentation is wrong. If possible, the bugzilla should be configured to not display this field. In any case, priority usage for this bug is currently inconsistent with the documentation.
Albert, please stop spamming this bug with silly attempts to justify your lack of research. It's not fooling anybody. Since you obviously don't have anything new to add to this bug, but instead whine about how you were caught being a fool, just please stop with this.
Albert, we are a handful of volunteers that deal with 10 to 20 bug reports per day. Are you trying to piss these hard-working volunteers off? Since that's what you are effectively doing. Now please, let us all get back to work.
Bug #158980 deals with a way to remove a good deal of menu entries, in particular the Logo scripts in the Toolbox.
Created attachment 46852 [details] [review] Image menu reorganization -- first pass Here's my first attempt at this. This isn't perfect. Two things that bother me: - Toys ends up being before all the menus that come from script-fu, because it's registered in menus/image-menu.xml and the script-fu ones aren't. Is there a way to control the order of script-fu registered menus? Alternately, if I put the new menus into image-menu.xml, if script-fu isn't there (are there platforms where script-fu isn't there?), do they end up being empty, or is the menu system smart enough not to show them? - Utils only has one item, Show Image Structure, because I moved the HSV graph into Colors. Unfortunately I couldn't come up with a convincing place to put Show Image Structure. Thoughts? Also, I made Animators a submenu under Animation. I think it's confusing to have Animators and Animation as siblings; but I could put all the Animators scripts directly under Animation, if anyone thinks that would be better. I don't often use any of these, but don't want to make things harder for people who do. I left Alchemy as a separate menu, in contrast to the proposal I posted to the list, because Rockwalrus suggested it deserved to stay separate. My proposal combined Glass Effects and Light Effects into one, but the current patch doesn't, largely because I was hesitant to make a menu string as long as "Glass and Light Effects". Personally I would probably call them all Light Effects and group them into one menu, and could easily do that if anyone thinks it's a good idea. My proposal also moved Enhance up a few spaces, to right under Blur, but I didn't include that in the present patch. I'd still like to do that if no one disagrees with it.
You should add placeholders to the menu structure where the scripts can register. Semantical placeholders if possible. We already do that in the XML files, have a look at how the Rounded Rectangle script is registered.
Created attachment 47405 [details] [review] Updated patch Here's an updated patch. It changes the following: - Moves python-fu as well as script-fu (and adds ellipses to all the python-fu entries). - Moves the Glass Effects filters inside Lighting Effects (lighting effects are listed first, then a separator, then glass effects, using placeholders). - Moves Enhance and Distorts up under Blur, just 'cause I think that's an easier order to understand, a few people agreed and no one objected. - Puts Unsharp Mask 2 (the script-fu version) after Unsharp Mask (the C version). It does this by cheating: I added a space before the ellipsis for the C version's name ("Unsharp Mask ..." instead of "Unsharp Mask..."). The other way I could see to do it is to add two new placeholders to the menu, one for each version of unsharp mask; I asked on IRC about that approach but we ended up going off on a tangent about the differences in the two algorithms and never reached a conclusion. So adding a space seemed like an easy solution for now, and easy to change if a change is wanted. - Removes the mnemonic from the second unsharp mask (the script one). Let me know if I need to make further tweaks or if there are any problems. I think the patch is usable now.
Using a space to differentiate the menu entries is not an option, I am sorry. This is going to cause problems in translations. You can't expect the translators to guess that this little glitch is done on purpose.
A useful distinction would be: a. serious stuff used for image repair and similar (color correction, cropping, alpha channel operations, rotation...) b. artistic stuff (toys like "emboss", "lens flare", etc.)
I hope it was clear from my comment that I consider the space a temporary thing, because no one could seem to agree on what they wanted done with the two different unsharp masks. I'll be happy to make a new patch with the two placeholders if someone tells me that's the desired approach.
The desired approach is to not use any hacks but to get rid of the second Unsharp Mask entry. You could open a new bug report about merging the two.
Filed bug 307535, and added it as a dependency here since it sounds like the menu reorg can't proceed until a decision is made on Unsharp Mask.
Why should this block the menu reorganization? Just continue doing that and ignore the fact that two Unsharp Mask menu entries exist and in which order they appear.
Did I misinterpret your comments? What to do about the double Unsharp Mask seems to be the only remaining issue with the patch. If there are other issues, please clarify and I'll be happy to make another patch.
An easy way to fix this: Unsharp Mask, native code Unsharp Mask, script Another easy way to fix this: Unsharp Mask (native code) Unsharp Mask (script) Yet another easy way to fix this: Unsharp Mask - native code Unsharp Mask - script
Come on, please ignore the Unsharp Mask issue. This is handled in a different bug report and doesn't have to be dealt with here. Albert, can't you just keep quiet? Your contributions to Bugzilla aren't in anyway helpful. Akkana, if you think that the patch is fine otherwise, that's OK with me. Someone will have to review it then, remove the Unsharp Mask hack and commit it. I am not sure if and when I would find time for this but there are other developers with cvs commit access who could be doing this.
I found time to try this patch and I think it goes into the right direction. The Filters menu appears somewhat crowded and unorganized after this change. The problem is that many of the Script-Fu menu entries are still not integrated with the rest of the filters but appear in submenus at the bottom of the Filters menu. This can probably be improved further. I wonder if it would be best to commit this patch and continue from there.
As said already, this will need more work. We should try to reduce the Filters menu by removing some of the less populated submenus. But this patch is a good start so I committed it: 2005-06-17 Sven Neumann <sven@gimp.org> * menus/image-menu.xml.in * plug-ins/Lighting/lighting_main.c * plug-ins/common/apply_lens.c * plug-ins/common/flarefx.c * plug-ins/common/glasstile.c * plug-ins/common/nova.c * plug-ins/common/sparkle.c * plug-ins/gflare/gflare.c * plug-ins/pygimp/plug-ins/clothify.py * plug-ins/pygimp/plug-ins/foggify.py * plug-ins/pygimp/plug-ins/shadow_bevel.py * plug-ins/pygimp/plug-ins/whirlpinch.py * plug-ins/script-fu/script-fu.c * plug-ins/script-fu/scripts/*.scm: applied menu reorganization patch done by Akkana Peck (bug #116145). * plug-ins/common/film.c: renamed filter to "Filmstrip".
Trying to summarize some of the things we talked about on IRC today so they don't get lost: Sven thinks (and I think everyone agrees) that there are too many items under Filters. I suggested moving Shadow up under Light Effects; but I'd hate to make it a submenu since Drop Shadow is so useful; how about light effects, a separator, then shadow effects, or even vice versa, shadow before light? I suggested Van Gogh should move from Map to Artistic. Generic, Alchemy and Toys are all quite short and should be merged, probably into one. I dislike "Alchemy" because I don't think it means anything relevant, Rockwlrs likes it, no one else expressed a strong opinion. I'd be fine with calling them all Generic, but Sven pointed out that the name doesn't say anything so it's not a good category name. No consensus was reached. Sven suggested the Color filters might go to Layers->Color. I thought the two items in Combine, Depth Merge and Film, should move somewhere else though I wasn't clear where since I'm not sufficiently clear on what they do. Everyone agreed that renaming Film to Film Strip would be a good idea, and rockwlrs suggested it should live in Alchemy (assuming of course that the name Alchemy stays). Perhaps Depth Merge could go there too. Clothify should move from Alchemy to Artistic, or perhaps be eliminated completely because it's very similar to Apply Canvas (though apparently they're not identical). Weave, IMO, should also move because it's also similar to Apply Canvas. That leaves only two items in Alchemy, but if they combine with Generic, Toys, and Combine we'd end up with a total of 8 items in that menu (taking into account the ones already mentioned as moving elsewhere). Unsolved: what to call that menu (do most people like Alchemy?) Whether to keep Clothify (I think we should unless we're convinced that it's identical to Canvas) and the two Toys (Sven made a mention of them going away, but maybe that just meant the separate menu going away).
Actually I didn't suggest to move the Colors filters to Layers-Colors. What I suggested is to add a new top-level menu entry "Colors" and move the content of the following menus to this new menu: Image->Mode (I'm actually not sure about this one) Layers->Colors Filters->Colors The rationale for this suggestion is that I think we make it too hard to do simple color manipulations. The functions to do this are found (or not found) deeply nested in multiple different menus.
Sorry, I misunderstood. Interesting idea! Certainly there are enough Color items to justify a top level menu, and making color items easy to find makes sense. Image->Mode does functionally belong with the other color items. I think moving it into Colors would make sense. How about Dialogs->Colormap? I know it brings up a dialog, but so do lots of the other Colors items.
Created attachment 48220 [details] [review] Patch, second round: shuffle entries around Here's a patch to do basically what I described in the last few comments, except for the color entries (I'll do those separately). Van Gogh, Clothify, and Weave move to Artistic. (I moved the Python Clothify too, although it isn't currently used.) Light Effects and Shadow combine into one menu, Light and Shadow, in which the Shadow items are grouped together. The Generic, Alchemy, and Combine menus get merged into one, which I called Effects. Items which used to be in those menus are grouped together using placeholders named after the old menus. Toys already seems to be gone so I didn't do anything about that.
Patch checked in. I'll do the color menus next.
Created attachment 50045 [details] [review] Move color entries to a new toplevel Colors menu Here's the patch Sven requested, moving the contents of Image->Mode, Layers->Colors, and Filters->Colors to a new top level Colors menu. It's kind of a long menu. I'll attach a screenshot. Might still be worthwhile since it's conceptually simpler. If the length of the menu is a problem, maybe some of the filters could be combined into a submenu -- or even all of them into one submenu, like <Image>Colors/Filters ?
Created attachment 50046 [details] Screenshot of new menu
The menu shows Colorcube analysis twice. Also, the Map submenu should be separated from the other menu entries like we do in other menus.
Last part seems a bit crowded, decompose/compose/recompose could go in mode, most of the items could get into a submenu as they are not so important, but channel mixer and filter pack stay in top level. Semiflatten seems better to be placed in layers or image. Value invert could go near the plain invert.
Created attachment 50157 [details] [review] Better Colors menu patch (still too long) This patch fixes the problems sven mentioned, and renames Mode to Image Mode as per gimp-devel discussion. The menu is still too long, and I agree with Guillermo that most of the stuff that came from Filters should go in a Filters submenu. I wonder about putting *compose into Image Mode since Mode seems so specific. They are used for somewhat similar purposes, but in a conceptually different way, and they don't necessarily act on the whole image (Decompose just works on one layer). They're important so I can certainly understand not burying them in a Filters submenu. Perhaps a Compose submenu next to Map? Or would Colors->Compose->Compose be too confusing? I'll have to take your word on Channel Mixer and Filter Pack. I don't really use either one very often. Color to Alpha is the most commonly used item in that menu for me (but it isn't important enough to stand alone, and would make sense in a Colors->Filters submenu). I think Filter Pack makes sense in Colors->Filters too. Could channel mixer share a menu with *compose? They seem conceptually similar in some ways.
Created attachment 50158 [details] what the menu looks like now
Looking at the proposal of merging all colors related menu items into a new top-level "Colors" menu, I fail to understand how these effects will work on layer level only.
Alexandre, looking at your sentence I am having a hard time to understand what you are trying to tell us.
Regarding comment #52, I don't think that Colors->Filters is a good idea. Filters doesn't really tell anything about the submenu. It is probably a good idea to introduce a few categories and move entries to submenus, but we should try to come up with meaningful terms for the categories. It might help to apply a technique from user interface design here. Print out all menu labels and cut the paper into pieces, one for each menu entry. Then ask users to group these entries. This should be done with users who have used GIMP and know what the labels (or most of them) stand for. Doing this with a couple of users should give you a good idea what categories would work best.
A discussion on IRC a few days ago came up with this idea: Add an Analysis menu for functions which analyze the current image rather than changing it. This would contain: Border Average, Colorcube Analysis, Histogram, Draw HSV Graph, and Smooth Palette. Also (as has already been suggested here) add a Compose menu which would contain the three functions Decompose, Compose, Recompose. The only thing I don't like about this idea is that it makes Decompose a little harder to get to, but it's still the same number of clicks that it was before Colors moved to the toplevel, so it's not really that bad. OTOH it might make people less likely to find Decompose, which would be a shame. With those two, the menu becomes a fairly managrable length -- it's still long but not much longer than the Filters menu. Re "paper usability studies": it would work well, if anyone has a set of users who would be appropriate for this. I don't know many GIMP users who are familiar with enough of the Colors menu to be good candidates (outside of #gimp, of course). Would it be worth posting on gimp-user? There hasn't been very much response to the thread on gimp-devel (not enough to get a reasonable sample, anyway).
Yes, such things should better be discussed on gimp-user.
The (long) Colors menu is in. The further reorganization to make the menu shorter is still under discussion. Sven and I talked today about possible ways of making some sort of online "paper prototyping" system, maybe starting from the fridge "magnetic poetry" demo. Failing that, maybe just a discussion on gimp-user.
The wiki page http://wiki.gimp.org/gimp/GimpMenus was intended for this purpose. Since nothing else is being done with it, you should feel free to make use of it.
A lot of progress has been made, and the current situation may be okay. I am going to raise the priority of this one to Urgent, because it is necessary to think about whether anything else should be changed before 2.4. If not, the priority can be lowered, and the target bumped to Future.
Noone seems to be working on this and we need to freeze our UI at some point. This is a good candidate for postponing to 2.6. Or should it be closed as FIXED and a new report opened?
I think it's best to close this report as FIXED. If someone wants to do an analysis of the menus and has good ideas for changes, a new report can be opened.