While this was already working when updating a filter through the GUI,
we could see the weakness in the code when updating through the plug-in
API (there, we could again reproduce problematic not-updated bounding
box, similar to #12294).
Since commit 543bb374a8 when
`gimp_help_domain_lookup_locale` returned NULL, we returned with
an error condition.
However, when a user with locale en_CA, or sv_SE tries to access our
help, it should not return, but try again with en and sv respectively.
Instead of returning, only call `gimp_help_locale_map` when locale is
not NULL. Then after that we continue with second pass processing
which will handle the above cases.
At some point, the code to show the label
for grids in dockable dialogues was removed.
(Possibly when GimpContainerGridView
was removed around 10e3a968).
This patch restores that code to
GimpContainerEditor to display the label
when selecting items in gridview in the
dockable dialogues.
While the pass-through group can be skipped in some specific conditions,
this won't work with filters (then the effect would only apply to the
one layer child instead of applying to the result of the child
blended/composited with the bottom layers).
This inconsistency was quite visible because people had to create 2
layers and have one as non-Normal mode for it to behave as actual
pass-through group.
Currently, if you open multiple files at once via the Open as Layers
dialog, it creates a new Undo History entry for each layer. As we
compress multiple layer operations elsewhere (such as deleting
or duplicating multiple layers), it makes sense to compress them
here as well.
12 bpc JPEGs currently load a blank image with a warning
that 12 bit precision is not supported.
libjpeg-turbo supports loading 8, 12, and 16 bpc JPEGs without
separate builds as of 3.0, so this patch adds support for loading
them and normalizing to 16 bit precision if needed.
Since we don't enforce a minimum libjpeg-turbo version, macros are
used to prevent this enhancement from being compiled if not supported.
In 2baa518a, to avoid a critical we use
the resolution as the width of GimpScaleEntry
when the unit is set to pixels.
This had the side-effect of making the
width of the GimpSizeEntry very long when
the unit is initially set to pixels.
Since GimpUnit is now an object, the original
critical no longer displays. Therefore, we
partially revert 2baa518a and refer to the
value as entry_width instead for clarity.
The minimum width is set to 7 to match
the minimum width of GimpSpinButton.
If you were to select a layer group and some/all its children, current
implementation was "flattening" all these at the same level, which is
weird.
Now the whole questioning of what to do in this situation is a very good
UX discussion to have, in particular when you only select *some* (not
all) of the children. Does it mean something? Does it mean you want to
copy part of the tree structure with only part of the children? What
when it's not a copy, but a move (e.g. a dnd in the same image). You
can't move part of the children (what do you do with the rest?).
Anyway that's many questions which I prefer to leave for a real gimp-ux
discussion and specification. For the time being, at least not
flattening a whole tree structure seems a better behavior.
When selecting by color with the Fuzzy Selection, Color Selection,
or Bucket Fill tool, we use gimp_pickable_get_buffer (). This only looks
at the raw pixels and not any active filters, which can result in some
unexpected selections (for example, an NDE offset filter will make it
appear as if you are selecting the wrong area).
There are plans to let users decide whether to select the raw
pixels or the filtered layer. For now, this sets the default action to
consider the layer as seen by the user, with filters included in the
calculation.
In 06bd1f1289 the max number of
dimensions was set to 1000, but the plug-in runs into a
segfault when dimension >4. The rest of the plug-in uses
GIMP_PIXPIPE_MAXDIM as max (4), so use it for the dimension argument
as well.
In particular, we want the new Script-Fu plug-in to be able to handle
their progress status themselves, which is possible with
(gimp-progress-set-text) except that it is far too quickly overriden
because each procedure call generates a new progress message.
I hesitated to make (gimp-pdb-proc-exists) public but I don't think it's
a good idea as it would be redundant with gimp_pdb_procedure_exists() in
the C API.
Instead, just implement (gimp-pdb-procedure-exists) specifically for
Script-Fu, with a name mapped to the C function.
Adding an is_internal value was a mistake, or rather it was redundant.
We already had a procedure type and all internal procedure are set as
GIMP_PDB_PROC_TYPE_INTERNAL.
I also double-checked that it is not possible for a plug-in to create a
procedure with this type (it is rejected), so it's very fine.
… gimp_procedure_is_internal().
I realized we were already naming these "internal procedures" in the
Procedure Browser and this is in fact a better naming than "core
procedure".
When closing the last image, it seems that we'd remove twice the
"windows-display-0001" item, first when making the action invisible,
then when gimp_ui_manager_remove_ui() is called on emptying the display.
And gtk_menu_tracker_remove_items() doesn't handle correctly a NULL
list.
Some people reported cases where gdb doesn't even seem to understand
Python scripts (the error in #12904 implies it is looking for standard
gdb commands, because apparently -x option allows both styles).
Others had issues in sandbox building (#12956).
I don't really want to spend too much time understanding each case,
especially as it's a self-debugging tool, not absolutely necessary for a
successful compilation.
So let's just make this optional, and default to "false".
