You are here

Should there be such a mess in the Menus?

At first let me say that I really love Gimp the way it is. But I think there is one point that could make it a little bit better. I think there is too much chaos in placing new plug-ins in the menus. The users loose the overview and have to search a lot for what they need. Plug-ins should be found where they belong: the layer-plug-ins in the Layers-Menu, the ruler-plug-ins in the View-Menu or Image-Menu and so on. Maybe for the most additional plug-ins there should be created an additional Filters-Menu, to seperate them from the basic stuff. And generally, I think the plug-ins should be aligned for what they do. Sometimes it may also be usefull to gather them under the names of the developers or so (for example G'mic or GAP). But in the most cases the users know what they want to do and search for certain functions to do it. And in that cases they will unnecessarily have to search for it or remember where they saw it last. That could be made better.


That could be achieved via a review process, i.e. set up rules, and then review new plug-ins and scripts that are submitted according to these rules.

However, this is probably more work than the current admin team can perform.

It's all up to the developers... nothing prevents them to use a menu tree or another. But... most developers never get any feedback, and so assume the users are happy with the current behavior Complain/make constructive suggestions to the authors... or since most plugins/scripts are in source form, edit your own version.

I have tried to do that in the scripts I create. For example, I created some scripts that generate gradients and registered them in the gradient menu. So many people asked "where is the script? I can't find it!" not expecting to look in the gradient menu.

-Rob A>

That's because all they see (besides our scripts) is more clutter in "Filters", but they will eventually get the hang of it, and maybe think about reading the docs or checking the script file itself for instructions...

My opinion on this subject is that it is the beginning of a very good feature.
For example I don't have the same interpretation of 'Filters ' that GIMP have:
the term has a connotation (for me) of changing the whole image like a camera filter, so perhaps 'Plug-ins' is a more appropriate term, but should I distinguish between plug-ins included with GIMP and those added later by me? Or make them common task oriented, etc.
Hope this illustrate why I consider it a good feature.

There is no absolute place in the 'menu' where a plug-in belongs, it depends on the user, if he/she control where and he/she has that control now. We should not stretch the GIMP developer convention past its usefulness for the developer (sweeping this feature under the rug). The actual diversity (mess) in the menu placement, in the first place, support that view.

So improvement should consist in facilitating, the menu placement, the user's way.
For a graphical desktop solution: probably not in next few years, unless you provide one.
But we can work with what we have now by giving more information.

Starting with the plug-in user:

1- During the adoption phase of a plug-in, there is a GIMP tool under 'Help/Plug-in Browser' to find some info, in particular the menu path for a plug-in if its not known. Also it gives examples of the menu path and there structure (important for the following step 3).
Here I will call the first element (separated by '/') of the menu path the 'root' and the last 'launcher', witch is in relation with the name given by 'Plug-in Browser'.
«For example if you search for 'Plug-in Browser' with that tool you get "<Image>/help/programming" without the launcher and the launcher is "Plug-in Browser".(Edited)»

2- If he/she come from close software (EULA), he/she has to change his/her mode of interaction with open software (GPL) which encourage poking inside (by using mostly text files) without fear of a catastrophe legal or otherwise; here it will be the '*.py' and '*.scm' files of the plug-ins to be adopted. Open them with a text editor (encoding of characters: 'utf8 -sans BOM' was ideal for '*.scm' ).
N.B.: you can also change '*.c' source files but it is more adventurous on Windows.

3- Find toward the end of the open file the one 'register()' function or more than one in some case. In the 'register()' look for the root of the menu path, it's one of
["<Image>", "<Toolbox>", "<Layers>", "<Channels>", "<Vectors>", "<Colormap>", "<Load>", "<Save>", "<Brushes>", "<Gradients>", "<Palettes>", "<Patterns>", "<Buffers>"] for GIMP-2.6, some change for other versions.
Often the root is "<Image>" and it will be used in the rest of the step.
Asterisks will point to the menu path or element of it. There are two main approaches: separation of launcher & menu path (left column) or theirs integration (right column) .
«To change the placement of the menu: modify the strings pointed by the asterisk(s) after the root, respecting the approach of the plug-in.»

launcher & path at the end of          complete path near the beginning of
  a) for '*.py' files with module 'gimpfu':

    register(                                         register(
     ...,                                              ...,
     "2012",                                           "2010",
*   launcher,                                   **   "<Image>/...",
     ...,                                               ...)
*   menu = "<Image>/...")
  with module 'gimpplugin' (example ''): the name of the function 
   is 'gimp.install_procedure()'.
  b) for '*.scm' files:

    (script-fu-register "script-name"                (script-fu-register "script-name"
*      launcher                                 **     "<Image>/..."
        ...)                                           ...)
    (script-fu-menu-register "script-name"
*     "<Image>/...")	

4- After changing a couple of menus it becomes a piece of cake and you have transform what at first seems a weakness to a strength. Then you can translate them, change the default parameters in the same 'register()' function etc.
(In my few plug-ins I make no effort to place the menu where «one» user expects it to be. In the long view to place it for her/him is a disservice to that user or unjust for the others. Now we will be able to point them to this comment, if it's understandable!)

5- «If GIMP is running when you change the menus of plug-ins registered in GIMP: you have to restart it if it's a Python one for your changes to take effect and if it's a Tiny Scheme one, you click on 'Filters/Scripts-Fu/Refresh scripts'. After you acquire a little experience you can experiment with changing the root of the menu path. In my experience, complication occurs in the integration approach if the root is '<Image>' (see suggestion 3 for the plug-in developer), don't be discourage by failure, play with it. In the present state of development of GIMP, it's a good thing for the user to know the 'register()' function.»

Ending with the plug-in developer:

Consist of establishing standards to simplify the job of the user. Here are some suggestions.

1- Some plug-ins has a refinement in the blurb which appears when we mouse over the launcher in GIMP.
It gives the file name of the plug-in associate with that launcher.

2- Use of variable for the menu seems not advisable because it complicates the user search for it.

3- While I was using the separation (left column) in my last script because the approach in the right column for "<Image>/..." in Python adds automatically and silently two parameters (image and drawable).
But it is simpler for the user and replacing "<Image>/..." by "<Toolbox>/..." stop this automatism (found that later!).
«After further thought on this, the left column approach is preferable: less complication overall and more flexible (ex.: you can have multiple menu paths for the same 'register()' function).»

4- If there is more than one 'register()' functions in the plug-in file, regroup all the 'register()' at the end of the file.

* «In a Python plug-in the second line should be
'# -*- coding: utf-8 -*-'
to simplify translation, even if the plug-in writer is not interested in translation.»

Many Thanks for the answers!

Especially the idea of a customizable menu-structure sounds verry interesting to me. I didn't even think about it.

One of the reasons why I wrote this thread is that I offered a Gimp-seminar at the evening school here in germany for some years. Many of my students were not that familiar to computers as they seemed to think. And most of them found it verry difficult to get into Gimp. For some of them it was already the second Gimp-seminar. And I fear some of them will still be unable to work with it.

So I think there is still a little work to do to make this amazing software more attractive to the public. And I think orderfull menus are one point to do that. Just consider it worth thinking about.

All the best to you all, ursa

Hi ursa_major,

My comment was at the level of a person who can manipulate files but if it's not the case then you cannot use it, sorry.
Perhaps better to keep your students away from the 'Plugin Registry', it will only confuse them further.
I think there are some version of GIMP with more hand holding built in (ingimp?), you have to inquire.

The default parameters are added depending on the menu you are called from. You cannot move code from one menu structure to another (say, to , without rewriting some of the code. I'm all in favor of the user fiddling with my code, but then it becomes his/her code, not mine, and I don't want to have to maintain it...

This said, what we seriously miss is a standard way to allow translation of menu items and labels in the UI (or proper documentation of the existing one).

Hi Ofnuts,

Your first paragraph indicates to me that something was probably not clear in my post. So I added a phrase inside '...plug-in user:' step 3-, in my comment, to try to clarify.

Edit: sorry, misspelling your user name was not intended.
Thank you.

Subscribe to Comments for "Should there be such a mess in the Menus?"