This way we handle all kinds of proxies (particularly buttons).
Also add a small hack that prevents extended multiline tooltips of
GimpButton from being overwritten by gimp_action_update_proxy_tooltip().
Note that it will only work for a model attached to a GimpMenu. In particular,
it won't work for the menu bar set to a GtkApplication with gtk_application_set_menubar().
In other words, it won't work on macOS where we let the OS handle the menu.
Use this for the "View > Zoom" and "View > Flip & Rotate" submenus which used to
display the zoom level and rotation angle. This regression is now fixed.
"edit-paste-as-new-image-short" and "vectors-selection-to-vectors-short" were
just duplicate of the action named the same, except for the "-short" suffix, and
the only point was to have different labels.
Not though that this time, it was not enough to conclude that the action in a
menu shoud have the short variant. These were both used differently depending on
the menu.
Instead I added the concept of "label-variant" attribute in .ui menu files. When
the "long" variant is set, then we simply use the longer label.
There is still one more "-short" action: "tools-by-color-select-short", but I am
a still unsure how to handle this one.
Basically actions in menus should show the short label (we assume the menu
position brings contextuality) when available, whereas it will use the longer
label in GUI lacking contextuality.
As a first such usage, the `file-open-recent-*` actions have the file name which
will be opened as short label. This is used in menus since the submenu `File >
Open Recent` ensures that the action which will run is perfectly understandable.
On the other hand, in the action search, the action is named 'Open "<file
name>"' since an action named only with a file name would not be understandable.
This is a continuation of previous work where we are slowly moving to most logic
being in GimpMenuModel so that it works both when we create menus ourselves or
when we let GTK do it for us (e.g. the main menu bar in macOS).
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.
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.
Also getting rid of gimp_action_get_proxies() API which is now unneeded, I
think. Furthermore GimpMenu does not have to connect to label changes. Making
the items proxies of a GimpAction is enough to have them updated.
The tooltip contains the reason for action inactivity, if relevant. And in case
of a GtkMenuItem in particular, it will also contain the "Press F1 for more
help" text at the bottom.
Not sure why gtk_actionable_set_action_name() works fine to activate base
GimpActionImpl, but not subclasses like GimpProcedureAction or GimpEnumAction
(and maybe others subclasses?), such as the "file-open-recent-*" actions. This
will have to be investigated further IMO.
The proxy properly shows a color area or viewable (depending on context), and
this is properly updated when the associated properties are changed.
The label change is also properly updated in the label part of the proxy.
Very relevant actions to test the proxy items are dynamically updated are
generated actions such as the "file-open-recent-*" actions (with both label and
viewable updates), or again the Edit > "Fill with (FG|BG Color)|Pattern" (with
color/pattern updates).
These are the menu items such as the recently opened images, or recently used
filters, etc.
Some notes:
- I added back a "placeholder" concept in the GimpMenu logic. This will allow to
place items at specific positions in the menu (either under the placeholder,
which will make the last item be on top or above the placeholder to have the
last item be in the bottom, depending on needs). Technically placeholders are
just menu items with a label (used as placeholder key) and no associated
action, which I will leave invisible.
- I add a logic for submenus so that they are invisible by default and are only
made visible when we add a menu item with an action in there.
- I removed filling the "/Filters/Recently Used/Plug-ins" placeholder. As far as
I could see, it was never filled (neither with old or new code) and the
"/Filters/Recently Used/Filters" actually already takes care of filling the
"Recently Used" submenu with both GEGL operations and plug-in calls.
- The old gimp_ui_manager_add_ui() API is for all types of menus, e.g. including
the ones created by dockables or elsewhere whereas my new API is (for now)
still specific to the top menu. This will have to be further implemented
later. I left a bunch of "TODO GMenu"-s for the time being.
- I see 2 dock-related generated items which seem to never be added, for
recently added and closed docks. It doesn't seem to work in the old API as
well. I'll want to have a closer look too.
Some actions in particular can change their label. E.g. "file-export" and
"file-overwrite" will have customized labels containing the imported or exported
file name. The menu will now reflect such changes, live.
I'm starting to override GtkAction properties, starting with "sensitive" in
order to finally move away from GtkAction. Obviously, this breaks the
sensitivity check of the original menu.
This demonstrates a first version of our replacing menu, using GAction and
GMenuModel. I had to make our own subclass of GtkMenu to process the model (from
a .ui XML file) for the following reasons:
* gtk_menu_new_from_model() doesn't support tooltips, which is a feature we use
quite extensively in GIMP: with all our filters, being able to give a longer
description is often useful; moreover we use tooltips to give hints about why
a menu item is deactivated as well.
Unfortunately it looks like GTK doesn't consider this lack as a problem and
don't plan on adding tooltip support.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/785
* I won't to avoid copying action's label and icons in the .ui file. This only
duplicates strings and would be a source of issues each time we change
action's strings (we'd have to do it in 2 places, which someone will
inevitably forget).
Now it still has various issues:
* The syncing between actions and menu items need to be cleaned up. It's still
in early demo code.
* It uses directly some Gtk*Action code because GimpRadioAction and
GimpToggleAction are not directly related right now (only through their
parents).
* gtk_application_set_menubar() might still be necessary on macOS as I think
it's what enables the native menu system on this OS. It means that we'll have
to edit the menu model to add back the labels (as this function does not
extract these from the linked action since GAction has no label or icon
concept).
* Icons are not taken into account right now.
* I'll have to verify if GimpAction with proxy work (but my guess is that right
now, it won't).
* Action's active state is not synced with menu item active state right now.
* Various actions are inserted live, such as opened images, opened views,
recently opened images, and so on. This needs to be implemented back.
* Plug-ins need to be able to create their own menu item into this new menu.
* For all these various reasons, I'm keeping the old menu around, for the sake
of comparison, until the time the new one becomes feature-full.
Part of this commit is inspired by !558 and obsoletes this MR.
