We have translations for ckb (Central Kurdish), which is only
available in iso codes 639_3. For our language selection we only
parse 639(_2), which causes this language to show up as `??? (ckb)`.
This is of course not a good user experience since users need to know
that ckb is the abbreviation of their language.
We fix this by parsing `iso_639_3.xml` instead of `iso_639.xml`. This
works, but, since this file is a lot bigger, it takes a lot more time
(more than 1 second difference) to parse this.
Now, this is only done on startup, but this can certainly be a
noticeable delay.
A recent addition to load layers in Sketchbook TIFFs contained a typo in
code specific to big endian machines, making it fail to build there,
which wasn’t caught in CI.
In addition to this fix, use the appropriately named macro to convert
from little endian to big endian.
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
… to keyboard input.
Removing a GtkBindingSet entry actually removes it from all GtkTreeView.
It's not limited to the ones contained in GimpContainerTreeView (which
makes sense, since it relies on the class) so it broke various
interactions across the software.
Let's just connect to signal key-press-event instead and block further
propagation. Not sure anyway why GTK has so many ways to handle key
interactions!
I'm also moving the implementation to GimpItemTreeView because this
enhanced keyboard handling is really about the items tree dockables
only, for the time being at least.
… icon name.
As akk was reporting on IRC, the huge question mark from the
dialog-question icon really makes it feel like it's an help button
(especially when used as an actual button, e.g. in GEGL filter generated
dialogs with aux inputs, when no viewable has been set as input yet).
Currently we can't serialize GimpDrawable, which is necessary for us
to store filters with Aux Nodes. Therefore, they will automatically be
applied destructively as a workaround until we can.
There was a weird instance of build failure in CI when compiling one of
the libgimpui files. It could not find one of the PDB-generated
function:
> ../libgimp/gimpaspectpreview.c:329:19: error: call to undeclared function 'gimp_image_get_selection'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
My assumption is that as a multi-threaded build, this file was compiled
just at the same time as the PDB was generating it, and therefore it was
empty, hence a very bad timing creating a build failure.
As I recall, I created the bogus stamp file stamp-pdbgen.h specifically
for such race condition issues (because meson has no generic dependency
rule, so we can't just ask one job to wait for another). We were using
this bogus object as source to libgimp, but not libgimpui.
Hopefully this will fix the problem and it won't re-happen randomly.
layers-select-next/layers-select-previous don't work well as up/down
arrow behavior because they only work within each selected layer's
level. But historically (and that's what makes the most sense IMO, and
is the most expected behavior), up/down arrows would walk through the
layer list visually. I.e. that it would select next whatever is the next
layer displayed in the Layers dockable, even if it means selecting
children or going down one layer group level.
The 2 new actions "layers-select-flattened-previous" and
"layers-select-flattened-next" do this. Say you have this tree:
Layer 1
Layer 2
| - Layer 3
| - Layer 4
Layer 5
With the "flattened" actions, after Layer 2, there is Layer 3, and after
Layer 4, there is Layer 5… unless… Layer 2 (layer group) is collapsed.
In which case, after Layer 2 is Layer 5. This selection movement indeed
takes into account the state of the layer group expanders.
This makes the Up/Down arrows work similarly to how they used to work
with default GtkTreeView implementation, except that the logic now also
works well with multiple selected items.
This reverts commit 31df873d4c.
My commit was not wrong per-se (it didn't add any bug), but it was in
fact not useful either, and only adding a useless list copy for no good
reason.
I thought that action_select_object() was actually selecting objects,
but looking at implementation, it in fact doesn't. It only returns a
pointer to the object to select.
This should likely eventually be re-specified in gimp-ux tracker,
especially as anyway we are planning on rewriting the GimpItemTreeView
from scratch.
But for now, this is better than the behavior where the arrow keys are
losing multi-item selections by default, and also the PageUp|Down
assigned actions are eaten away (as noted by Jacob in #11729).
Now we still don't go through to the PageUp|Down actions (in fact we do,
if we consider the default ones, but it's hardcoded, because after
careful consideration, I do indeed think that when such a tree view has
focus, the arrow and PageUp|Down buttons would have special meaning
anyway), even though I had a first version of this patch which did this.
We simply have much nicer hardcoded behavior!
Somehow it works fine on my machine, but this is very likely the
culprit. gimp_image_get_selected_layers() returning directly the pointer
to selected layers, we should always make a copy before doing anything
which would change this selection!
Resolves#11897.
The crop tool currently doesn't constrain
to the top-left of the layer when the
"Allow growing" option is turned off and
"Selected layers only" is turned on.
Instead, it always constrains to 0, 0.
When we converted to multi-layer select,
we added a loop to check the boundaries
of all selected layers. In this loop, we use
separate variables to get the offset and
then get the min of it and the current
min_x and min_y. However, those values
are initialized to 0, so they will always be
smaller if the layer is inside the canvas.
To fix this, before the loop we check if
there are any selected layers. If so, we
get the offset of the first layer and set
min_x and min_y to that value rather than
0, 0.
...bump map settings.
Currently, the Lighting Effect's bump map options uses
the RGB values of transparent pixels as part of its map.
As the Bump map filter does not do this, this patch tries
to make it consistent by using associated alpha for the
bump map Babl format to fix this.
Resolves#11892.
The new_unit_dialog () now initializes the default GimpUnit
to NULL instead of GIMP_UNIT_PIXEL. So we need to update the
check to prevent it from running when the user cancels the dialogue.
First of all: sorry to all translators who started working on these new
strings!
We use CamelCase for our titles, and in particular "Plug-In" is
capitalized with 'I'.
Furthermore, let's use understandable titles like "Plug-In Example in C"
and not just "In C", because while the short title works OK in the menu,
it makes for very broken action names in non-contextual parts of the
software, such as the action search.
Note that we in fact have a concept of short label for actions since
commit 89772351c9. I added support for it to GEGL actions (cf. commit
6dc5f6792e), and to a few core actions (e.g. commit ea1205f094).
Unfortunately I don't think I added an API yet for short label in
plug-ins. Maybe I'll add it soon. But for now, if we have to have a
single label, it should be long, so that it works in every situation.
P.S.: not sure if it's useful to keep documentation strings just
repeating the title, but for now, let's leave them.
Resolves#11890.
The Selection Editor's "vectors" group was not renamed
to "paths" during the GimpPath API update. This caused it
to be registered to a non-existent group, thus crashing.
Jacob Boerema