I can create a sub menu in the filters menu with: procedure.add_menu_path(“/Filters/MySubmenu/”) and procedure.set_menu_label( “MyEntry”]). It displays properly into Filters then there is a MySubmenu menu and then it opens up and show “MyEntry”
I can create an entry WITHOUT sub menu in a section like this procedure.add_menu_path(“/Image/[Scale]/”) but this displays MyEntry directly under “Scale with image…”
What I want is a sub menu MySubmenu inside the [Scale] section. But nothing works.
procedure.add_menu_path(“/Image/[Scale]/MySubmenu/”) creates a submenu at the bottom with [ and ] around Scale. Basically [Scale] is not interpreted as a section if it is not the end of the path
Tried self.add_menu_branch(“/Image/[Scale]/”, “MySubmenu”) but it does nothing. I guess add_menu_branch does not support sections
Thank you for confirming the issue and filing the bug, it was driving me nuts thinking I was doing something wrong. Will wait for a fix in a future version.
Yes please. A pull request would be very appreciated.
You may find where the path is processed in function gimp_utils_break_menu_path in file app/widgets/gimpwidgets-utils.c. Now updating this function would be very easy. I guess that instead of a section_name string, it could return a section_names array of string of the same size as the returned array of paths. I.e. that for each path, an optional section name could be associated or not.
Changing this function should be extra easy. Now of course, you’ll have to find the various usages of this function and fix them to the new signature. And in particular, the usage in GimpMenuModel is where things will get a bit more complicated (though of course very doable!). You’ll want to find the right section item at each menu level.
In any case, a patch is very welcome. And we don’t bite.
To discuss more easily, we are very available on IRC at #gimp in GIMPNet.
Thanks, I got the code compiled and running. Looking into the modification now.
Do I really need to change the function signature? I only want one section like now, I just want to be able to create entries in a submenu in that section instead of the section itself directly.
Will check out IRC to discuss.
Do I really need to change the function signature? I only want one section like now
Well yes, but you want it either in the end submenu, or somewhere in the middle. How would you know where this subsection goes in the menu tree otherwise?
Now we could specify this menu path as allowing only a single subsection, at any level in the tree, but:
Then you would need to add say an index as returned integer (or some other way) to advertize to which menu level the section name goes. In other words, you’d change the signature anyway.
This seems an artificial restriction! In the first implementation, it made sense to have a single section name because it was made to only work for the last level. But if we decide that we can add a section name in any level, it definitely makes sense to say we can have section names in several levels too.
In any case, whatever you were to do, you’d have to change how the calling code is processing the return data from parsing this string. So you may as well do it well and generically. It should not even be much harder.
I just want […]
I mean, if you want to submit a MR for sharing this improvement with the whole world — which would be great! —, it needs to be done the correct, generic way. Not special-cased to your one plug-in.
Also if you actually just wanted to special-case the code for your plug-in (and did not care about submitting a generic patch for all), so as to have your custom build of GIMP, I would not even bother editing this code if I were you! I would just add the plug-in directly in the menus (as all our core plug-ins). That would be the simplest (but would not be a contributable patch).
But of course, I’m hoping the goal is to go further than this and to implement a generic logic for allowing people to set section names wherever in the menu path! And therefore to contribute this path upstream.
This seems an artificial restriction! In the first implementation, it made sense to have a single section name because it was made to only work for the last level. But if we decide that we can add a section name in any level, it definitely makes sense to say we can have section names in several levels too.
Thanks, I understand better now what you are thinking. Is that the case now? Do we have sections within sections? If yes then I agree it needs something like you described.
I mean, if you want to submit a MR for sharing this improvement with the whole world — which would be great! —, it needs to be done the correct, generic way. Not special-cased to your one plug-in.
Yes I agree, but I was also thinking about not over engineering it. Improving the current feature step by step depending on what is being asked and needed. My goal was not to add a feature to set section names, which I agree could be a desirable feature, my goal is to add another desirable feature to be able to add submenus to a section. I can see how those could overlap though if you want the submenu to become a section.
Thanks, will check out the code and see what I can do. Returning multiple sections does not seem to be a problem.
How would the sub sections be created in your mind with the current add_menu_path?
—, it needs to be done the correct, generic way. Not special-cased to your one plug-in. 