Especially some remnants of when Gimp(Toggle|Radio)Action were not descendants
of GimpActionImpl and had to reimplement GimpAction interface.
Also fixing a few details here and there.
As a further optimization (even though the big slowness situation is
mostly resolved anyway by a previous commit), let's not rebuild whole
submenus when only a few items were added or removed.
1. First make so that the action "visible" property is only notified
when the visibility actually changes. This way, we can trust that the
visibility of the item and of the related action are properly synced.
2. Now when an action which is part of a model changes its visibility,
we trigger the proper "items-changed" only for the added or removed
item. This replaces the old procedure of removing then adding
everything (i.e. a full reset).
3. Add some utilities in gimpwidgets-utils (out of gimpmenushell.c).
This cleans up some code and also fixes some bugs which were
reimplementing (badly) some code I already implemented (right) in a
static function.
4. Fix adding new actions in sub-sub… menus. Previous code was only
showing the direct parent, not up to the root menu (this could happen
for plug-in procedure items in particular).
Since GAction don't have labels or visibility, it is up to every application to
fill the GMenuModel with such infos. In my previous implementation, I was simply
handling these in GimpMenuShell subclasses (GimpMenu, GimpToolbar and
GimpMenuBar) since we need them for tooltip support (unavailable from GMenu).
Nevertheless there are cases where we want to use GTK API directly with a
GMenuModel, in particular with gtk_application_set_menubar(). This is necessary
to handle the macOS specific code path, where we don't want our usual menu bar.
This OS has its own display of a software menu bar, directly in the desktop GUI.
See !558 for some screenshots of this.
So this commit moves around some code away from GimpMenuShell subclasses into
the new GimpMenuModel class. Now we use this new class instead of simpler GMenu
objects. It handles syncing with GimpAction-s, auto-updating labels, visibility
and sensitivity, as well as adding custom items (plug-in actions, recently
opened files, opened images, etc.).
My last commit message was slightly wrong. I had one last special case to
handle: the ability to only create sub-GimpMenuShell (i.e. at a specific path
other than the root).
We are using this ability in particular for tool options submenus.
Somehow the toggle actions were not working correctly on GimpMenu popped up e.g.
as dockbook menus (but it was fine in the GimpMenuBar). I straightened up the
code to be a bit clearer. I also rely on the "toggled" signal rather than
"change-state" (the latter is supposed to happen before state change actually
happen). It now works much better.
Several menus can be triggered either as popups on their own when right-clicking
the dockable or on items, or as a submenu in the docks main menu.
In the former case, we want the menu items to be at the root level, whereas in
the latter case, we want them inside a properly named submenu.
To handle this, I wrap these in a properly labelled <submenu> in the .ui files,
and I add a boolean flag to gimp_menu_shell_fill() which will drop the top
submenu if and only if this is the only top item. I use this flag only when
using these menus as popup menu on their own.
Also fixing a few memory leaks around these pieces of code.
… group name.
The gradient editor submenu add 2 submenus with changing names. It was using
again bogus actions: "gradient-editor-blending-func" and
"gradient-editor-coloring-type" do nothing except for being used as name
holders.
Instead I add the concept of group name for GimpRadioAction-s and when I use a
radio action attribute as <submenu>, this submenu will use the group name (and
sync with it, if it changes).
I only translated the undo menu into GtkBuilder's .ui format for now.
The only missing part is that the icon is now shown.
Note that in various parts, I don't rely anymore on a bogus menu action (i.e.
"undo-popup" action in this case) which does nothing but has an associated label
and icon. I simply add the label and icon as submenu attribute directly in the
.ui file, which is translatable and whose strings should be parsed by gettext.
Eventually I'll just get rid of all the various "*-popup" or "*-menu" bogus
actions.
The new GimpMenu is derived from GtkMenu. Both GimpMenu and GimpMenuBar are now
implementing GimpMenuShell which allows to share a lot of the logic for filling
the menus, adding items, etc.
