Building on d8d8e7a0, we add a gimp_layer_tree_drop_viewables ()
function to handle dragging and dropping a pattern onto a Vector
layer in the layer dock.
Adding on to 9e277c39. The Ink Options
blob shape enum was also affected - this
fixes the margins so that all radio buttons
in a vertical button box are visually the same
width.
916cf84e handles dragging and dropping colors
onto vector layers on the canvas. However, we did
not handle what happens if you drag and drop onto
the layer dock.
This patch adds logic to gimp_layer_tree_view_drop_color ()
so that it also updates the vector layer fill, instead of
treating the vector layer like a raster layer and filling the
whole layer with the color.
On Windows gtk_clipboard_store ignores the number of items we have
set to be stored, instead storing all. Since this can be a long list,
shutting down GIMP on Windows can take considerable time when you
have a larger selection on the clipboard.
So we manually stop handling every target larger than 1 (png) and even
stop handling png after the first time, since it often gets called
multiple times for png.
The Hessele runner started to complain about the artifacts size and
the macports/ dir as artifact is not needed on a non-splitted job.
It was a leftover from the inspiration from Flatpak scripts.
(On Flatpak it is needed becase if we don't pass .flatpak-builder as
artifacts the gimp job will not know that babl and gegl were built)
When MacPorts or Homebrew prefix is the standard one, not a custom installation,
let's use the host macOS/SDK since this is the expected by both toolkits which
provide binaries only for host. Otherwise, we get warnings from the linker.
(We will keep assuming LSMinimumSystemVersion is desired on custom installs,
like our officialy distributed binaries which are built from a custom install)
More preparition to x64 support
As a ugly regression, it will not be possible to create .dmgs on
forks anymore without an explicit "Run pipeline" from a Developer.
I hope to fix that when we take our sponsored runner from CircleCI.
Some JPEGs contain large Photoshop path metadata split across multiple APP13 markers. Collect all APP13 payloads and skip the repeated "Photoshop 3.0\0" identifier for subsequent segments so the metadata can be parsed as a single stream.
Resolves#15969
It is possible to set the number of color components
in the JPEG 2000 file separate from the color space,
and OpenJPEG reports that value as-is. This can result
in a buffer overflow if the num_components variable is
larger than the number of channels in the color space.
This patch adds a check to make sure num_components
is within range. If it's larger, then we clamp it to the maximum
value for that color model.
The variable 'cntr' represents the index of all control points of a Photoshop path. It was declared too small, which caused problems with detailed path objects. 'num_rec' is of type 'gint16', but the number of control points is 'num_rec * 6', so 'cntr' must be able to cover that range
...when there is only one page.
The TIFF load dialog appears when either there are
multiple pages, or we need to make a decision about
how to render the alpha channel.
The "Show reduced images" was shown in both situations,
even though it is not applicable when we only have one page.
This patch modes that code inside the "if (pages->n_pages > 1)"
condition to prevent it from showing when it's not needed.
Error message:
Calling error for procedure 'gimp-image-set-selected-layers':
Procedure 'gimp-image-set-selected-layers' has been called with value '<not transformable to string>' for argument 'layers' (#2, type GimpCoreObjectArray). This value is out of range.
A few things were not clear, if not even kinda wrong.
E.g. the returned effective color profile docs was confused about
returning a preferred profile; or saying that an image can have no color
profile assigned is confusing (it's true, but it sounds like it means
the image has no profile — which makes no sense —; whereas it actually
means the image uses a built-in profile).
… gimp_image_set_simulation_profile().
It looks like NULL through the PDB for 'bytes' argument gets passed as a
GBytes of size 0 (which might be something I did, and to be fair, that's
fine; I just forgot having done this).
As a consequence, testing for NULL was wrong, and these 2 functions were
always failing with NULL. Now they behave appropriately.
I also improve the docs for both functions.
The function's documentation was already saying that we could set no
profile, except that in reality, setting NULL for the profile was simply
failing. Unless one checked the return value, the failure is also quite
silent. So let's actually implement what the docs say.
Also the concept of "default" profile might be a bit unclear in GIMP as
it could mean either built-in profiles or preferred ones (as set in
Preferences). I chose the former for this function, so I reword this
part of the docs.
I noticed that the issue of the combo box popup getting immeidately
closed on Linux X11 (and probably macOS as well) only happens when using
GimpUnitComboBox as used in gimppropwidgets.c and gimpsizeentry.c while
there is no issue when used in gimpstatusbar.c
The only noticable difference I saw was that in status bar was that
the wrap width of combo box was set to 1 via
gtk_combo_box_set_wrap_width. Which was added as a hack for another
issue.
I did the same for the other two uses of GimpUnitComboBox and the issue
disappeared so I moved this hack to GimpUnitComboBox itself as it seems
to be generally useful.
The change doesn't make much sense to me and is a workaround for
something that should probably be changed in GTK but well.
As explored in !2654 I think we shouldn't use GtkComboBox but reimplement
using a Popover. This would get rid of these workarounds as we wouldn't rely
on internal behaviour of GtkComboBox.
Couldn't test macOS or Windows but Linux X11 and Wayland work just fine.
Tested by: GDK_BACKEND=x11 gimp and GDK_BACKEND=wayland gimp
Fixes#12491
Superseedes !2654
With a cell size half the width of a grayscale image with an alpha
channel, we get a crash because we write outside our buffer.
When computing the offset in the buffer, we added the offset of the
tile, but since we are just writing this tile. We should not add that
offset.
