Commit Graph

7 Commits

Author SHA1 Message Date
8a8914bc21 app: a bit of code cleanup.
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.
2023-04-20 15:36:11 +02:00
228af9c3c1 app: only update the menu items which changed.
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).
2023-04-12 22:07:09 +02:00
1637dd1cd4 app: new GimpMenuModel object, which is our own implementation of GMenuModel.
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.).
2023-04-12 22:07:09 +02:00
f492871e88 app: better use GimpMenuShell and shift around some code as virtual…
… function implementations.

I am also preparing to create a new class GimpToolbar which will make good use
of the interface too.
2023-04-12 22:07:08 +02:00
9c7469fb22 app, menus: handle the case where a menu is used both as popup and submenu.
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.
2023-04-12 22:07:08 +02:00
7af01cbb16 app: new GimpMenu widget and GimpMenuShell interface.
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.
2023-04-12 22:07:08 +02:00
06b7242cc0 app: rename GimpMenu to GimpMenuBar.
This is better in sync with GTK naming (GtkMenuBar), but especially, it will
allow me to make a GimpMenu subclass of GtkMenu.
2023-04-12 22:07:08 +02:00