Some GIMP-custom GEGL operations do not use GimpConfig to
store their properties (for instance, Threshold).
Previously, we weren't copying over their values when editing an
NDE filter.
This patch adds code to copy over the Gegl properties if there is
not a GimpConfig object attached to the filter.
When working on #9712, I encountered this crash first before the main issue
(with the same reproduction steps as listed by Wormnest): reason may not be set
by the method. It's better to always explicitly set this variable to NULL first.
The list of objects where the config object is a dedicated custom class (instead
of a runtime-registered class) is well known. These are the operations
registered inside gimp_operations_init().
The list inside gimp_gegl_procedure_execute_async() which the previous commit
was updating was not right: it was still missing "gimp:hue-saturation" and
"gimp:threshold" should not have been on the list (this was generating a
CRITICAL when trying to get the "config" property on this object).
Instead let's add some init/exit() functions in gimp-operation-config API to
distinguish the operations with custom config (registered during init) with all
the others. Then we add gimp_operation_config_is_custom() which can be used
everywhere where we want to verify if an operation is using a custom-made config
object or a generated class just mirroring the operation properties.
This way, we should not get out-of-sync anymore.
Adds gimp:color-balance to the list of
GIMP-specific GEGL operations we
retrieve the GimpConfig settings from.
Also prevents trying to set a GEGL
property when editing if it couldn't be
converted properly (e.g. GimpConfig)
This patch implements an initial form of
non-destructive editing. Filters now stay active
instead of being immediately merged down.
A new column is added to the layer tree view, which
can be clicked to show a pop-over menu.
Filters can currently be hidden/shown, edited, reordered,
deleted, and merged down from this pop-over menu.
Currently, this works on layers and layer selections only.
Plenty of room for improvement!
Due to GObject Introspection we can't have the last part of an
identifier start with a digit, since that part will be used in Python
as the identifier, and Python doesn't allow that to start with a digit.
e.g. GIMP_ROTATE_90 would be used in Python as
image.rotate(Gimp.RotationType.90)
To fix this we add DEGREES in front of the number, without a '_',
even though that looks ugly.
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.
The anchor and merge down buttons are visible at the same time, which should not be the case.
Their visibility is now dependent on the existance of a floating selection.
The New Group and Search/Link buttons are also disabled when there's a floating section.
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.
A first attempt at fixing this was going through the idea of changing the
concept of radio actions, such as allowing an active action in an action group
to be called again. Or having some action in the radio group which can be called
but never set active.
But in fact, I just realized that these zoom actions are simply not meant to be
radio actions. They are not stateful actions, nor are they exhaustive.
I also updated the `other_scale` storage logic. Instead of updating it each time
the zoom changed (which was even broken in some cases, like when changing zoom
through another action), I simply save the last custom zoom value. This is the
one which is reused across calls. I don't think always resetting to the current
zoom value is very useful (if you call this dialog, it's not to zoom to the
current zoom!). Also there was some concept of flagging this stored zoom value
as "dirty" by making it negative, but this was never actually used, which makes
me believe that current logic was not the original intent anyway.
Saving the previous custom zoom explicitly set seems to be a good enough
behavior, so let's go with it.
The Microsoft style guide and other places online suggest that using a
hyphen is recommended between a number and the related word, when modifying
a noun, so let's do that in our Image -> Encoding submenu too.
Even though it's just for 3 dots, this may actually be formatted differently in
different languages. Let's not assume we all share this punctuation mark.
Resolves#9636.
gimp_object_get_name (gimp_display_get_image (display)) returns NULL
instead of the filename. documents_raise_display was changed to call
gimp_image_get_imported_file () or gimp_image_get_file() instead to
get the actual filename.
For all the test-ops thus far in gegl, gimp:menu-label has been
the same as title + "..", to keep the number of duplicate strings
that need to be translated and the number of needed boiler-plate
lines of meta-data in GEGL down, this is the default behavior when
a title key exists.
Instead of unconditionally add all the non-special-cased GEGL operations into
the menu, only insert the ones which explicitly use the new "gimp:menu-path"
GEGL key.
See new operation "gegl:adaptive-threshold" added in commit 7c2a70eee for such
an example.
Note that the other operations will still get their own generated action (which
means for instance that you can still search them through the action search and
that you can create custom shortcuts for your favorite actions). But now you
won't get an overlong generic list of non-organized actions in a single submenu.
Some people were finding this messy when they had a lot of custom GEGL ops.
Also it means that GIMP doesn't assume that any custom GEGL op is usable in
GIMP. Indeed some ops are really not meant to be used as filters, which is why
we have the gimp_gegl_op_blacklisted() internal function; but this cannot apply
to custom operations. Therefore from now on, instead of GIMP guessing, operation
developers will have the say on whether their op should show in menus and in
which menu path exactly!
Moreover the "gimp:menu-label" key will be used as short label, i.e. the label
which is used in menus in particular, where the menu path is a helpful context
(hence allowing to use shorter menu labels).
The main "title" will still be used as long label, for places where there is no
such context, for instance the action search.
When reverting commit d51c64ec06 and reimplementing as fa2e9adc29, the code to
make sure the generated per-op action name is unique disappeared. This code
ensures that the action name is indeed unique, otherwise the action will
override a previously registed action, which could be made from a plug-in, or
even by another GEGL operation. Indeed, while GEGL operation names are supposed
to be unique, they are post-processed to be valid GIO action names. So it is
totally possible to have 2 GEGL ops with different GEGL names, yet the same
GAction name.
The layer resize to selection and crop to content menu commands were
using the same help ids. This made it difficult to have them both listed
separately in the index of the manual.
Since we use separate help ids everywhere else for menu commands, let's
give each its own help id here too.
If "data" is a GimpItemTreeView or a GimpImageEditor, we REALLY want
only the image from these dialogs, even if NULL, and NOT some other
image from a display or context that randomly is around anyway. Fixes
the sensitivity states of lots of buttons in these dialogs.
Apparently this has never worked until we refactored our menus, now it
suddenly does but not as originally intended. Simply remove the
accelerator and let only the canvas event handler deal with the Tab
key. Restores 2.10 behavior which was quite ok.
Fixes#9352
In !769, I accidentally removed the ability to paste into an empty
workspace with Ctrl+V since I added a "does image exist?" check before
the `edit_paste_as_new_image_cmd_callback ()` call.
This patch resolves the issue by moving the check after the
"paste as image" function call.
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.
With our old code, we needed dummy actions for every submenu. This is not needed
anymore. Actions are only for end menu items (items which actually do something,
not just open a submenu).
Get rid of them all, as well as the code to ignore any action ending with such
suffixes in action-listing pieces of code.
Use this for the "View > Zoom" and "View > Flip & Rotate" submenus which used to
display the zoom level and rotation angle. This regression is now fixed.
Though it actually worked in some cases, and failed in others (I have not
figured out which build option exactly makes the format with hole work anyway),
printf manual actually explicitly says:
> There may be no gaps in the numbers of arguments specified using '$'; for
> example, if arguments 1 and 3 are specified, argument 2 must also be specified
> somewhere in the format string.
This explained while it was crashing GIMP (again, only with some build options,
or lack of build options):
> *** invalid %N$ use detected ***
There were 2 possible solutions for this: either ensure that the order number is
always used, but that defeats the purpose of plural localization. Instead I
reorder the argument so that the file name (which must always be shown for sure)
is first in arguments. This way, even if the order number is sometimes omitted
(be it in English or in any language), we avoid the crash.
Just "Layers" or "Patterns" was always very confusing. It was even worse when
both tools and dialogs had nearly6 the same name (for instance "Gradient" was
the tool action, but "Gradients" was the dialog).
Now these dialog actions will be labelled more obviously in the action search,
such as "Layers Dialog" or "Gradients Dialog".
Of course, the short name will stay in contextualized menus, such as in the
"Windows > Dockable Dialogs" top submenu, or in the Dockbooks' "Add Tab"
submenu.
While the short label can be "Gradient" for instance, because it is in the
submenu "Tools > Paint Tools", this is a confusing label say in the action
search.
Now the longer label will be used in there and will say:
> Activate tool "Gradient"
"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.
All Gimp*ActionEntry (except GimpProcedureActionEntry) now have a short_label
member.
This commit doesn't add any new short label yet. It just fixes the struct usage,
and fixes a few localization contexts here and there when I saw such broken
strings.
I also fixed a few gradient editor action strings which were not proper labels
(like "splitmidpoint" or "splituniform", or missing uppercase, etc.).
The short labels are just the file names as we have all the context in the menu
to understand what these actions do (in Windows menu, ordered by view position
and with a `Ctrl+n` shortcut next to each, increasing by position).
In the action search for instance, we keep a 'Show "<image name>"' label.
Also I'm adding a relevant tooltip to further explain what each of these actions
do, using the view position.
Basically actions in menus should show the short label (we assume the menu
position brings contextuality) when available, whereas it will use the longer
label in GUI lacking contextuality.
As a first such usage, the `file-open-recent-*` actions have the file name which
will be opened as short label. This is used in menus since the submenu `File >
Open Recent` ensures that the action which will run is perfectly understandable.
On the other hand, in the action search, the action is named 'Open "<file
name>"' since an action named only with a file name would not be understandable.
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.
Same as ZoomIn/Out keys, these are implemented as secondary shortcuts to actions
"windows-show-display-next" and "windows-show-display-previous" respectively.
See issue #637.
- The `accelerator` variable is a NULL-terminated array, allowing up to 3
accelerators per action (so far, none has more than 2).
- Only the struct GimpProcedureActionEntry still has a single accelerator as I
don't think it makes sense that we change the plug-in API to allow a plug-in
to register more than 1 shortcut for a procedure (e.g. we don't want a plug-in
to just register all possible keys for their procedure!).
Of course, users will still be allowed to register more shortcuts for plug-in
actions through the shortcut dialog. It's only the initialization which
1-shortcut max for procedure actions.
- Remove all actions ending up in "-accel" as these were only a trick to
register more shortcut for a same action. Now we just have the real
possibility (rather than creating bogus duplicate actions). As a consequence,
these actions accelerators have been moved as secondary accelerator to their
main action.
The deleted actions are: "view-zoom-out-accel", "view-zoom-in-accel",
"view-zoom-16-1-accel", "view-zoom-4-1-accel", "view-zoom-2-1-accel" and
"view-zoom-1-1-accel".
I've hesitated if we should make it a GActionGroup, whose API handles actions
fully through name strings. I didn't see what it brings us short-term compared
to the additional work, so for now it's just a class of its own, not
implementing GActionGroup interface. Maybe later.
Pre-GIMP-3.0 code logics would re-allocate several GimpMenuFactory or
GimpUIManager for no good reason. While it was still working with old GtkAction
code, with our new GAction-based code, we were ending up overriding an action
with a new version of the same action, while keeping reference to old actions.
This made for discrepancies of the enabled or visible state of actions.
The new code keeps singleton of some objects and references to already
registered GimpUIManager or GimpActionGroups objects and make sure no actions
with the same name are created twice.
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".
… 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).
While in the menu, under a contextual "Open Recent" submenu, it is well
understandable, the action is much less understandable without context, e.g. in
the action search. So I prepend an "Open" prefix.
Maybe a future alternative could be to have GimpAction have both contextual and
non-contextual labels (a.k.a. short vs long label)?
"windows-show-tabs" and "windows-use-single-window-mode" were set to FALSE by
default, while it is now supposed to be TRUE, same as the config properties. The
discrepancy was only showing with my new GimpMenu which better follows the
action's state.
All the remaining pieces of code where the deprecated concept of accelerator
closure was still used have now been replaced by proper GimpAction API using the
newer GAction API.
Depending on the OS, the display name may contain characters which are not valid
for action names. In particular, on X11, the display name could be ":0.0" and
therefore we get actions named "app.dock-move-to-screen-:0.0" or
"app.view-move-to-screen-:0.0". The ':' is invalid, which will make calling
gtk_application_get_accels_for_action() (or more simply our new function
gimp_action_get_accels()) fail.
See docs of g_action_parse_detailed_name().
The new utils function gimp_make_valid_action_name() will help us get rid of
invalid characters for actions whose name was generated from strings we don't
totally control.
Furthermore gdk_screen_make_display_name() is now deprecated API, and more
generally gdk_display_get_n_screens() is deprecated too and now always returns 1
since GTK+ 3.10 (i.e. now each display only contains a single screen). Instead
we just use gdk_display_get_default_screen() for every GdkDisplay. So this
commit doubles as GTK/GDK deprecation cleanup.
Adding a 'Show" before the image identifier, which is now between quotes, and
making this string localizable.
This makes the action more understandable, especially when listed in
less-contextual UI such as the action search.
… "Add La_yer Masks with Last Values".
Add the "with Last Values", otherwise the shown label is the same as
"layers-mask-add" action, which is confusing (until we read the longer
description/tooltip).
...no image is active.
There are Arbitrary Rotation options under both the Image and Layer
menus. All of those rotation options are disabled without an image open.
To keep consistency, this disables those menu options as well.
The Tools menu Rotation option is left as-is.
When a plug-in enters a bogus file name such as "Untitled.xcd" as URI,
g_file_is_native() returns FALSE. So when saving such file, core code tries to
mount a remote volume and fails (of course), without even opening the file
dialog.
This change is an attempt to detect such cases beforehand and not even try to
save it (just open the file dialog directly; the file name is still useful as
default proposed file name, as this part is actually valid).
Actually remote files will have a valid URI anyway (something with a valid
scheme, such as https:// or whatever other scheme).
As side fix, I am adding a missing space to the error which I got.
Rename "Crop to Selection" to "Resize Layers to Selection" since it's not
necessarily a crop. The layer dimension can also grow now.
Also specifying "Layers" because action titles can also be displayed
off-context, such as in the action search, so we must be more detailed with our
action titles. Similarly adding a "Layers" to "Crop to Content".
- Duplicate and Delete Paths are now both callable on several paths at once.
- Path Edit and Edit Attributes can only be run with exactly one path selected.
- Merge Visible Paths obviously always worked with more than one path.
- "Discard Text Information" work on all selected text layers.
- "Text to Path" creates as many paths as there are selected text layers.
- "Text along Path" still only works with exactly 1 text layer and 1 path
selected.
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).
When several drawables were selected, it was pasting at the top of the layer
stack. Instead, paste over the top selected layer ("top" visually in the Layers
dockable).
There was the question of: what should we do when pasting over a layer group.
Should we consistently paste the new layers above the group or inside the group?
After discussions with Aryeom, we decided to stay consistent and paste above, at
least for now.
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.
The action "select-float" should probably only work for a single selected
drawable anyway since a floating selection can only be stacked on one drawable
at a time.
Actions "vectors-fill*" and "vectors-stroke*" require a single drawable to paint
to. So action logic is unchange. I only replace gimp_image_get_active_drawable()
by gimp_image_get_selected_drawables() and counting the drawables.
Alx Sa