The GimpProcedureDialog API allows int and double SpinScales. However,
it calls gimp_prop_widget_set_factor () which requires doubles.
A conditional check for a double property was added to this call.
A check was also added to ensure int properties have a factor of 1.0.
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.
Though the GEGL Operation tool is still useful as a generic dialog, let's
generate also per-operation (the ones not ignored and not already special-cased
in the rest of the GUI) tools and actions.
These "tools" are mostly hidden (e.g. not selectable in toolbox where it would
be a bit useless as they would show with the generic GEGL icon or none), but
they can be searched with the action search, shortcuts can be assigned and they
can be added to menus.
Sabri Ünal