I hesitated a lot whether we should just drop the whole localization of
plug-ins' label and description (blurb) within the core. Actually the
commit messages I wrote a few days ago were moving towards this logic.
It really looks to me like plug-in localization can happen fully within
plug-in themselves. As far as I can see, the only advantage which the
current logic has theoretically is that if we needed, we have access to
both the original strings and their translations (e.g. it could be
useful for text search). Nevertheless I am not sure if we will ever make
use of this, and this is limited cases as all filters turned GEGL ops
don't have such ability anyway.
Nevertheless since previous contributors clearly put quite a lot of work
on this code of localizing the plug-in's label and description within
the main binary, I want to give myself a little more time to think and
study the whole thing because doing anything rash.
In the meantime, what changes is that by default now, a plug-in without
a local gettext catalog is simply not localized. In particular, the core
process doesn't try to localize it using the default catalog, a.k.a.
GETTEXT_PACKAGE"-std-plug-ins" ("gimp30-std-plug-ins"). It just doesn't
make sense and the worst which could happen would be to get unexpected
and wrong translations.
Now by default, plug-ins will try to find a catalog in their main
folder, named as this folder. If it fails to find it, a message is
printed to stderr and localization is disabled (rather than falling back
to a default catalog). It is up to plug-in developers to either install
a catalog, or implement set_i18n() to give the right catalog, folder, or
disable localization with gettext, as handled by libgimp.
Reviewer (Jehan) note: cherry picked from MR !274. Still deciding
whether this will be pushed to gimp-2-10 branch too.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
app/display/gimpdisplayshell-draw.c
app/plug-in/gimppluginmanager-call.c
libgimp/gimp.c
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
libgimpwidgets/gimppreviewarea.h
libgimpwidgets/gimpscrolledpreview.c
It can be argued that layer groups can't be painted on, and that's
probably the original reason, but it's really just the same as "Lock
pixels". It is interesting to be able to lock alpha channels on a layer
group to simply lock all its contents alpha channels.
Since we are now allowed to move groups (which is the same thing as
multi-selecting all its children and moving them), it makes no sense
that this lock is disabled.
This works the same way as "Lock pixels" in that a locked grouped also
forbid moving children. And there was already some logics so that you
can't move a layer group if one of it's children is locked. So this lock
really works both ways and is a bit special.
Finally I cleaned up a bit the multi-layer selection logics and
messaging, as well as which lock to blink (similar to the previous
commit) for the "Lock position" case.
In particular, if painting on a layer whose parent's pixels are locked,
we were blinking an empty lock spot, which is confusing. Now
gimp_item_is_content_locked() will also return the proper item (when
relevant, i.e. when returning TRUE) which is locked. It may or may not
the same item as passed in (it may also be a parent item in particular).
As the name implies, this is an action to toggle the paint dynamics ON
and OFF which can be a huge time saver when painting and needing to
switch between dynamics and non-dynamics painting.
I have not been adding this action in the "dynamics-action" group
because these are only used for the dynamics dockable menu. Also it
looks like the context actions are not visible in the action search (I
can't recall why, but I think there was a reason), yet you can still set
a shortcut.
Should we create a new "paint-action" group maybe?
I cleaned many remaining places where the concept of linked item still
survived.
On loading an XCF file with linked items, we are now going to create a
named sets for the linked items, allowing people to easily select these
back if the relation was still needed.
We don't remove gimp_item_get_linked() yet and in particular, we don't
save stored items into XCF files. This will come in an upcoming change.
Similarly to how I improved "Select Top|Bottom Channel", we should set
the actions sensitive not only when the selected layers are not the
top/bottom ones, but also when there are no selected layers at all.
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.
I first sink these, because they are floating references. This is
actually quite unneeded here, because callbacks given to
gimp_action_group_add_procedure_actions() (this is what
filters_history_cmd_callback() is for) are not taking ownership of the
GVariant anyway. Yet just in case this ever changes, this is the proper
way to do it to avoid a double-free in the future. We take ownership in
the calling code, hence we free the variable there after using it.
This function is not only used as "response" callback to the merge
dialog, but also called directly with a NULL dialog in
image_merge_layers_last_vals_cmd_callback().
This commit fixes:
> (gimp-2.99:130330): Gtk-CRITICAL **: 22:17:59.774: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed
Reported by Massimo.
On most keyboards the [ and ] keys are shared with { and }. Which means
that if you press Shift+[ you get {. We were using this key combination
to increase the tool's size by 10 and the other to decrease it by 10.
However, on all keyboards where these keys share the same physical spot
on the keyboard, this wasn't working.
So, let's change the actual keys to do this to { and }.
When a selection exists, we are copying then pasting the selection
contents. In particular, with multi-layer selection, it means pasting a
merged result of the selected layers (like a sample merged but limited
to selected layers).
Yet when no selection exists, with a single layer selected, a cut in
particular would remove the layer fully, then a paste would copy it
elsewhere (in the same image or even on a different image). This was
still working, but not with multiple layers. This is now fixed and we
can now copy/cut then paste several layers (without merge), which is
sometimes a very practical way to move layers (sometimes simpler than
drag'n drop, especially between images).
As a consequence, the PDB function gimp_edit_paste() now also returns an
array of layers (not a single layer).
In some cases, in particular for actions generated from plug-in
procedure right now, we were displaying the reason of the insensitivity
(typically right now, only the drawable type is cited). This was done by
appending the reason to the tooltip, separated by 2 newlines, which
resulted in extra ugly design, no nice way to style this info directly
(with pango for instance if the widget display allows it, or on a
separate info widget in a possible future, or whatnot).
Also it would mean that the action search could match a disabled action
by mistake if a search word happens to be in the reason message.
This improves the situation with the following changes:
* gimp_action_set_sensitive() now takes an optional reason string to set
the reason message.
* Same for gimp_action_group_set_action_sensitive().
* gimp_action_get_sensitive() returns an optional reason string.
* gimp_procedure_get_sensitive()'s tooltip return value now becomes a
reason (it won't contain anymore the tooltip and the reason
concatenated, only the reason for separate processing).
… single drawable run() function.
All Scheme scripts use a single drawable and I am not so sure where to
change this (or rather I hope someone will handle this rather than I).
So let's not output a warning which would result into a stacktrace,
blocking the GUI for a second or 2 and displaying an annoying popup each
time. Let's just output to stderr for now until we get into a better
state.
which will be shown when selected template pixel density don't
match the image pixel density.
Then user can either keep current image ppi and scale the
template or set image ppi to match the template ppi.
Density selector displayed only when template and image ppi
differs and template unit is matches one of real world units
(e.g. inch, mm, etc).
Closes: GNOME/gimp#1140
… drawable array instead of a single drawable.
Instead of expecting a single drawable, GimpImageProcedure's run()
function will now have an array of drawable as parameter.
As a consequence, all existing plug-ins are broken again. I am going to
fix them in the next commit so that this change can be easily reviewed
and examined if needed later.
I only fix the Vala demo plug-in now (or rather, I just use the first
layer in the array for now) because otherwise the build fails.
The new function gimp_procedure_set_sensitivity_mask() allows plug-ins
to tell when a procedure should be marked as sensitive or not.
gimp_procedure_get_sensitivity_mask() retrieves this information.
Currently plug-ins are automatically marked as sensitive when an image
is present and a single drawable is selected. Nowadays, we can have
multiple selected layers so we should allow plug-ins to tell us if they
support working on multiple drawables. Actually we could even imagine
new plug-ins which would be made to work only on multiple drawables.
Oppositely, there are a lot of plug-ins which don't care at all if any
drawable is selected at all (so we should allow no drawable selected).
Finally why not even imagine plug-ins which don't care if no image is
shown? E.g. plug-ins to create new images or whatnot. This new API
allows our core to know all this and show procedure sensitivity
accordingly. By default, when the function is not called, the 1 image
with 1 drawable selected case is the default, allowing existing plug-ins
easier update.
Note: this only handles the sensitivity part right now. A plug-in which
would advertize working on several layer would still not work, because
the core won't allow sending several layers. It's coming in further
commits.
Since we now hide the file dialog when exporting, progression ends up
invisible, which is especially a problem with big files. Therefore use
the image display as a GimpProgress to show progression.
We were also reading "gtk-show-unicode-menu" which has also been
deprecated since GTK+3.10, and we were not even using the read value.
Just remove this piece of unused code.
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).
Check at runtime for the operation availability and set the "Show Image
Graph" action active depending on this check.
This goes with discussions to make this operation optional with a
runtime check for the tool `dot`.
See: https://gitlab.gnome.org/GNOME/gegl/-/merge_requests/84
The issue has also been fixed on GEGL side (see commit 5ac40e3c3 in
GEGL), but since the fact that "gegl:introspect" relies on a runtime
tool (which is not the best thing), let's make an additional check
within GIMP to make sure we have a proper buffer as a result to
"gegl:introspect". Otherwise we might crash when trying to use this
NULL buffer.
I had recently created gimp_item_is_ancestor() but realize it duplicates
gimp_viewable_is_ancestor() (which works on GimpItem since it's a parent
class). No need for duplicate code.
