Though no error was raised during a native build, a cross-build was
choking on this missing link to libgimpbase and failing.
The error returned by the linker though was a bit amiss.
Fixes:
> gimp-test-clipboard.o: In function `test_clipboard_copy_callback':
> tools/gimp-test-clipboard.c:419: undefined reference to `g_file_get_contents'
> collect2: error: ld returned 1 exit status
(cherry picked from commit 0865e9db1f)
It seems that calling `lldb` when it is absent triggers some popup
proposing to install Xcode on macOS. This is obviously not good. Let's
check presence with g_find_program_in_path() instead. I was refraining
from doing so until now, because this function allocates memory, hence
may not do well during a crash.
Fortunately we don't need to check for lldb during crash (unlike gdb
which has some unacceptable behavior for older versions, at least on
FreeBSD) so that should be ok.
In gimp_group_layer_update_size(), never suspend drawable updates
(and, in fact, remove the option to suspend drawable updates
entirely,) and instead never update the drawable during the call to
gimp_drawable_set_buffer_full(), and flush the group's projection
*after* setting the drawable's buffer, so that any pending updates
will happen after the group's buffer and size are up-to-date.
This fixes some missed drawable updates.
In GimpProjection, change gimp_projection_add_update_area() to take
coordinates in the projection's coordinate system, rather than the
image coordinate system, and move the offset adjustment to the
projectable invalidation handler.
Modify gimp_projection_projectable_structure_changed() to pass
projection-space coordinates to gimp_projection_add_update_area().
gimp_projection_get_buffer() and
gimp_projection_projectable_bounds_changed() already pass
projection-space coordinates to gimp_projection_add_update_area(),
which was wrong before, when the projection had a nontrivial
offset, but is correct now.
Add a Babl space parameter to gimp_gegl_color_new() and all utility
functions using it. Pass NULL if the GimpRGB actually is sRGB, pass
the image's layer space if the color was already converted using
gimp_pickable_srgb_to_image_color() or similar.
Fixed by implementing Massimo's two findings:
gimp_operation_cage_transform_process(): if aux_buf is NULL, bail out
after initializing out_buf with identity vectors, fixes the crash.
gimp_cage_tool_create_filter(): set the drawable filter's region to
GIMP_FILTER_REGION_DRAWABLE, fixes offset when there is a selection.
AppStream spec says it can only contain <p>, <ol> and <ul> markups.
Unfortunately these are not pango markups (nor is there any equivalent).
So I just use newlines and spaces until I figure out anything fancier.
That's all still quite ugly, but whatever, I'm still in the start.
Not the most useful type of extensions per-se, but a lot of people seem
to appreciate creating and installing new splashes. Let's make it easy
to install as extensions.
Note that extension splashes are cumulative. So if you enabled several
splash extensions at once, an image would be chosen in random amongst
all of them.
It was using deprecated functions regarding how icons used to work, such
as gtk_icon_set_get_sizes() or gtk_style_context_lookup_icon_set().
The last uses of this function disappeared in last commit.
... GimpCellRendererToggle into "icon-size".
In particular making it a pixel size instead of a GtkIconSize. This enum
is limited to a few presets (registering new values is deprecated since
GTK+ 3.10), with names completely semantically wrong. It is better to
specify icon sizes (before scaling) in pixels directly, which goes also
with named icons instead of stock ones.
...image using "Sample Average"
Also fix gimp_gegl_average_color(), which is where all current
implementers of GimpPickable actually calculate the average.
In GimpCanvasTransformPreview, add the necessary bits to the
preview graph so that, when transforming a layer, the layer's
opacity and mask are correctly applied to the preview. Note that
since we're still not rendering the preview as part of the image
graph, the output is not always accurate, but it should be good
enough in most cases.
Jehan