Fixes#9883
There were menus that put their entries
directly in the tab menu rather than in a submenu.
This moves them to submenus to bring back GIMP 2.10 behavior.
Stray entries added by scripts are also moved to the right
submenu.
Though we mostly removed floating layers/masks (formerly floating
selections) in many interactions, at least for default behaviors for
basic pastes, there are still advanced usage attached to this concept
and some advanced users are willing to have easier access to such items.
For this reason, this commit:
- adds edit-paste-float and edit-paste-float-in-place for pasting the
contents of the clipboard as floating data with default positionning
algorithm or in-place respectively;
- renames select-float to select-cut-float which does a cut and paste as
float in one action;
- adds select-copy-float which does a copy and paste as float in one
action;
- reorganize a bit the `Edit > Paste as` submenu with sections for the
floating data variants;
- add a "Float" submenu in "Select" root menu, containing the 2 variant
actions select-cut-float and select-copy-float.
This comes with a "colormap-delete-color" into the "colormap" action group. The
action/button will be insensitive when the selected color is used in the image,
since it is only possible to delete unused colors.
It's nearly the same list of placeholders which will make it easier to
third-party developers (though format still changed, devs will have to add
square brackets for section names).
Now some section names are missing because we would need to break some list into
smaller sections yet want to avoid having separators everywhere. This makes me
wonder if removing my first placeholder implementation was the right idea.
Anyway this new implementation is cleaner and we should find a way to add
sub-sections without creating separators in menus.
Also I didn't try to add new section names (though I did once or twice, e.g. a
"Close" section around quit/close actions which didn't exist) but eventually we
should. Being able to name logically parts of the menus will make them even more
organized (if we can't name a group of actions, it may mean we didn't think
properly the organization and order).
File/Quit, Edit/Preferences|Input Devices|Keyboard Shortcuts should not be in
the main menu bar on macOS because they are already in the "app menu".
See #9322.
I'm not sure what's the default for random string attribute, but better be
explicit anyway. I think this way, we make sure that gettext won't try and
translate these.
This removes a bunch of inconsistencies we had from the before-2.99.16 version
because new items from plug-ins were all added at the bottom of their respective
submenu.
Now that we don't blindly generate a messy list of all non-special cased actions
in Filters > GEGL Operations, "GEGL Graph" is all alone in this submenu. It just
makes sense to bring it back to the Generic submenus where it used to be.
Per @Jehan, this solution would prevent default icons from being loaded
in custom themes if they did not include their own version.
The only thing kept from !909 is the replacement of hardcoded strings
in a few files with constants defined in gimpicons.h.
Five icons in the Layer dockable were being replaced by GTK defaults at
runtime. A "gimp-" prefix was added so that GIMP's version would always
be used. A few dialogues were fixed to use constants rather than
hardcoding the filename, to make it easier to update the icon in the
future.
"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.
Since we now generate actions for GEGL ops, we might as well generate menu items
for these too.
What I did:
- Move the "GEGL Operation…" tool (generic dialog with a drop-down list of all
non-ignored GEGL ops) to Tools menu.
- Create a "GEGL Operations" submenu in Filters > Generic.
- Move "GEGL Graph" to the top of this new submenu.
- Generate a new menu item for each generated action tied to a GEGL plug-in,
alphabetically sorted.
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
It was actually working fine except that I wrongly named the submenu somehow,
but even more particularly I thought it was about single dockables (tabs)
whereas it was about full detached docks (a window containing several
dockables/tabs).
Only remaining API are action group-related.
While doing this, I also remove 2 debug actions which don't look like they were
outputting any information anyway (at least on the main dev branch):
"debug-dump-items" and "debug-dump-managers".
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.
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 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).
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.
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.
When the clipboard contains raw image data or single layers, it's the same as
the normal "Paste" (and "Paste In Place" respectively). These actions are useful
if you want to copy a bunch of layers and paste them "merged" into a single
layers (since now the copy-paste of multiple layers will create multiple
layers).
It is somehow similar to the "Copy Visible" action except that it works on
selected layers only and work at paste time, making the action more versatile.
There are so many paste options and I feel that the "Paste into Selection*"
actions are advanved enough that they can go into submenus. So I move them into
"Paste as". The other reason is that I'm going to add 2 more options!
I hesitated to rename the "Paste as" submenu but we couldn't find a good naming
(except just "Paste" but it's redundant with the default action and "Paste…" but
this usually implies a dialog, not a submenu).
Last but not least, I renamed the various paste actions to contain the word
"Paste" in it. E.g. s/New Image/Paste as New Image/. The old naming made sense
when action labels were only displayed in menus. But nowadays they can be shown
in other more independant context, such as the action search (and just
displaying "New Image" in there is very misleading).
This changes the default selection pasting behavior to be a new layer,
rather than a floating selection. It also removes the
"Paste as New Layer" submenu options as they are now redundant.
Adds a simulation_profile to GimpImage to allow plug-ins to access it
for CMYK import/export.
Two pdb functions were added to enable this access:
image_get_simulation_profile () and image_set_simulation_profile()
Next, it updates menu options and code to support GimpImage's
internal simulation profile. Menu items are moved from View to Image's
Color Management section.
New 'simulation-profile-changed' signal is emitted via
GimpColorManagedInterface so that relevant tools (such as the
CYMK color picker, GimpColorFrame, and future dockable
dialogue) are aware of these changes.
Action "view-rotate-reset" renamed to "view-reset" (resets both flipping
and rotate). New "view-rotate-reset" and "view-flip-rotate" for
resetting rotation and flipping respectively.
Anders Jonsson