In particular on macOS, we want to show some default common actions (see
comments in !837) but gtk_application_prefers_app_menu() docs says that it will
always return FALSE on this OS. So we ignore this call on macOS.
Depending on where it's used, this list of action can be either in the
"dockable" or the "dialogs" action group.
The meson rule is a bit more complicated than I wished it were because of the
ever-so-blocking lack of simple dependency in meson.
Cf. my latest comment: https://github.com/mesonbuild/meson/issues/8123#issuecomment-1496168759
… 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 dialogs-menuitems is shared between dockable-menu and image-menu, just as it
was with the old format. For this, we use XSL transformation with XInclude, then
drop the namespace (because GTK doesn't like the unknown namespace being defined
and crash immediately otherwise).
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.
Basically the build was never running this target (unless maybe in some
edge cases as could be demonstrated by the Arch repository build, though
it doesn't look they did anything particular; this is how we discovered
the bug #6447 as this was not run on our own local or CI builds).
Reading the docs of run_target(), it may actually have been normal.
run_target() looks to be only about creating top-level targets (which
one could run with `ninja validate_menus` in our case for instance), not
actually running the command (i.e. badly named function).
For the command to be actually run on a normal build, let's use a
custom_target() as proposed by Paolo Bonzini. After testing, the xmllint
validation is properly run on a normal build and dependency works fine
with both the source XML and generated XML files (touching these files
trigger a rebuild).
The output of xmllint is stored in some dummy file, which is only useful
to prevent re-running the command at each build even though source XML
were unchanged (so it's more of a flag file).
See discussion in #6447.
No input to use. Also comparing to the autotools build, we were not
validating against the DTD, hence adding --valid now.
The other difference was that instead of looping through all XML menu
files, we are doing the check in one command. After a few tests, it
seems to work fine this way too and errors are still accurately given
(telling which file/line has issues), so I leave this difference as-is.
Also this rule is apparently never run (except when explicitly), which
is why we never discovered this bug until today. It would seem that
meson 0.57 would now run this rule, which is nice. But we should check
it is run appropriately (always when any dependencies are changed, never
when they are not), just like with the autotools build.
Jehan