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.
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.
See the discussion in #5339. Basically this is now technically a tool
(i.e. a child class of GimpTool) and tools can be activated anytime,
even when no images are opened, i.e. when they are useless (for instance
paint tools). Filters on the other hand were historically only
activatable with opened images. With time, tools and filters difference
got slimmer (until there are technically none nowadays where GEGL ops,
levels or curves are implemented as GimpTool too) if not only a
conceptual difference.
Since here GEGL Operation is really more on the "filter" side, let's
just move it to the "Filters > Generic" submenu, just next to "GEGL
Graph", also removing the mention of it being a "tool" from the help
message.
Then I will merge !402 for it to be (in)active depending on images, as
other filters do.
The input menu added with gtk_im_multicontext_append_menuitems() mostly
provides redundant (e.g. the system defaults) or useless options
(e.g. "None" or "Simple" which basically seems to mean the keyboard
mapping straight keys, and I don't see why anyone would want this if one
set a system-wide input system). Worse it can provide unstable options
(e.g. "Wayland" which crashes GIMP when I tried it on my X11 desktop! It
crashes on _gtk_immodule_wayland_init which is probably normal as we are
not on a Wayland client).
Anyway gtk_im_multicontext_append_menuitems() is deprecated since
GTK+3.10, as well as the "gtk-show-input-method-menu" property which we
read from GTK+ settings (and is FALSE anyway nowadays by default, so we
usually never show this submenu) to determine if we should show this
additional text tool submenu or not. Furthermore there is just no reason
not to leave the defaults system input method engine does its job (which
works well as far as I can see, at the very least on my GNU/Linux X11
desktop and on Wayland also, last I tested).
A -quick done- first step towards the addition of a smart selection tool.
Require the gegl:paint-select workshop operation.
Still LOT of work to do (wip):
- fluctuations removal (GEGL side)
- multilevels pyramid approach + banded graphcut for instant result on large
image (GEGL ? GIMP ?)
- Gaussian Mixtures for color models (GEGL side)
- drawable offsets (GIMP side)
- undo / redo (GIMP side)
- scribbles edition mode (GIMP side)
- dedicated icons
- ...
mr.fantastic