Branch for the move to GAction/GMenu (aka end of GTK+3 port!) - issue #7649

Putting it here so that it's not lost whatever happens. This is the code where we replace GtkAction with GAction/GMenu. It obsoletes !558 (closed) (only took some stuff from it).

The whole implementation is nearly there, though there are still a few things to handle. The GtkAction code still is there, but is less and less used. For the record, there are 2 menus right now, the old and new one, but it's mostly to compare them. This will be easy to remove in the end.

Of course, it's a huge workfield. I tried to summarized what I did so far and what looks like there is still to be done:

• All Gimp*Action classes are now also GAction (both while being GtkAction).
• Our actions are now stored in the GApplication. Note that they are also still added, in duplicated, in the GtkActionGroup-s, so actions shortcuts are conflicting right now; I haven't removed the old logic yet on purpose.
• Search action using GAction
• Shortcut editor using GAction
• Unique action checked using GAction
• GimpLayerTreeView uses GAction directly.
• GimpToolButton uses GAction directly.
• The toolbox color area uses GAction directly.
• Quit dialog uses GAction directly
• Actions in status bar use GAction.
• Various actions labels are being renamed in the process, to be more understandable without the context of a menu (for instance in the action search). Alternatively I've been thinking that we could have a second API gimp_action_set_long_label() which would be used in non-contextual cases. Good examples are:
  • The file-open-recent-* actions in short forms are just file names, which turn out to be much nicer under an "Open Recent" submenu, which not so in the action search with menu context.
  • Similarly for the windows-display-* actions showing opened images.
  • The tool actions should have a "tool" appended. For instance, the Scale tool action shows up as "Scale" only which could easily be confused with the Scale Image or Scale Layer dialogs, and should have a longer "Scale tool" name in the action search list. On the other hand, under the Tools menu, the short name is fine (better even, i.e. less redundant).
  • All actions ending in -short are apparently there to have a "short label" variant for a same action.
• Removed the "can-change-accels" feature. It was actually not working anymore because it is based on a feature in GTK+ which has been ignored since GTK+ 3.10. If we want to get this back, we'll have to reimplement it ourselves in the future.
• Completely got rid of the accel closure code (e.g. gtk_action_get_accel_closure() and all things we were doing with the closure) which is a deprecated concept with no equivalent. This was used in various parts of the code. So I now do things differently.
• Got rid of deprecated gtk_action_get_accel_path() and gtk_action_set_accel_path() functions.
• gimp_action_activate() now uses g_action_activate() instead of gtk_action_activate() so all code still using GtkAction for various things actually use the GAction API for activating the action itself (at least for simple actions without a state).
• Added a valid action name concept with gimp_make_valid_action_name() utils function as we sometimes needed to create dynamically action names (in particular for the "*-move-to-screen-*" actions).
• Top menu using GAction/GMenu: nearly on par with the original menu, but still a few details to check:
  • Created a new GimpMenu child class of GtkMenu, which does a lot more things. In particular, it supports tooltips, unlike the GtkMenu (and apparently GTK is not planning on adding support after being asked: gtk#785 (closed)).
  • All default actions are specified in an image-menu.ui file, like in !558 (closed). Note that I don't add labels, nor shortcuts nor anything else in the .ui file, because these are already attached to the GimpAction and duplicating this data is wrong (we'd necessarily end up with discrepancies when people will update once place and forget the other, etc.). So I'm filling the labels, tooltips and so on from the GimpAction associated to each menu item itself.
  • Plug-ins can now add their own actions to the GimpMenu, like they used to do on the old menu.
  • Various generated menu items, such as recently opened files or recent filters are now added as well.
  • A few of the generated menu items don't seem to ever get filled. It was apparently broken even with old code. I'll want to get a closer look at these and decide what to do (i.e. drop them or fix them).
  • Only the basic tooltips are shown for now. We'll want to show the advanced tooltips (with Pango markup and more info like the inactive reason).
  • Proxy item support in the GimpMenu.
  • Showing main action shortcut next to label.
  • Plug-ins used to be able to place their menu item more accurately using placeholder items. Reproduce this ability?
• Dockable menus and canvas menu should use GAction/GMenu too.
• macOS is a special case. If I understand correctly, it doesn't have the top menu, but a menu is available (I think?) in the OS UI itself. Apparently GMenu/GTK has support for this. Cf. this message, and I am guessing this is what gtk_application_set_menubar() does. If confirmed, it means on macOS, we'll be limited to the GMenuModel and we won't have tooltips for our top menu on this platform (@lukaso mentionned in a comment: "macOS never had tooltips on the menu (at least not implemented) so this is not a big loss."). Also I'll have to fill the menu model, with labels, generated items, plug-in items, the same way I fill currently our GimpMenu. @lukaso I'll be in touch with you when I'll come to this. Right now, I believe your macOS native menu will contain a lot of items without labels, etc.
• Get rid of GtkAction entirely and correctly re-parent the various Gimp*Action classes to each other for sharing more code.
• Make decisions about what to do with GimpActionGroup. I think we may want to keep the concept of action groups (though it's barely ever used, expect in the shortcut editor), simply not with GtkActionGroup, and doing a lot less things.
• The GimpUIManager will probably stay but the parenting to GtkUIManager will have to go.
• The GUI feels a bit slower to appear at startup (though I haven't timed it). At the very end, when I'll have removed all old code, would be nice to time and investigate things if still needed.
• Test what happens if a plug-in create an action with the same name as an existing action.
• We will now have the ability to have several accelerators per action (see #3891, #637 (closed), #3834 (closed), #6612 (closed), maybe #5404, and all actions which end in -accel). We must make use of it:
  • In the shortcut editor;
  • Removing the duplicate actions which we created here and there when we wanted to have 2 default shortcuts for a given action.
• What about adding the ability to show the main menu path in the action search? (#5601 (closed))
• Handle storing and loading shortcuts with the new logic (old code using gtk_accel_map_load/gtk_accel_map_save doesn't work anymore with GAction stored in the GtkApplication's GActionMap).n
• Add code to transform old menurc to new shortcutsrc after update.
• Some stuff are currently broken in non-English languages. Make sure the whole code is not language-dependent.