There is no non-hackish way of fixing this without adding a new
"use-opacity-paint-mode" property to GimpToolPreset and a new toggle
in GimpToolPresetEditor. Restoring opacity and paint mode can now be
controlled explicitly, and defaults to TRUE.
(cherry picked from commit 97b714d428)
If we don't do this, the clipboard owner doesn't get unreffed (also the
GtkClipboardClearFunc is not called either, but we don't set any so this
was not a big problem).
The main consequence was that copying was setting the Gimp object as an
owner, which kept a reference and prevent its finalize() method to run,
hence was leaking data (and in particular some GEGL buffers for
clipboard operations, which was how the issue became more visible upon
exit).
(cherry picked from commit fca6371e29)
Properly initialize GimpSelectionTool::saved_operation upon
modifer-key press, even when some modifiers are masked out by
GimpPolygonSelectTool while the tool is active. This avoids
erroneously "restoring" the operation to a previously-saved state
once the modifier keys are released.
(cherry picked from commit e0a5aaeb22)
Remove the "CMY" model from compose and decompose, it's gone from
babl. Also fix decomposing to CMYK by using the right component names.
(cherry picked from commit f3f8d3a54e)
Change while() to go from 0..360 instead of 0..361 so the code passes
automated tests. The code never ran into this situation but the change
is a small improvement anyway.
(cherry picked from commit 452924dbe9)
By only doing the snapping to white/black for whitest/blackest palette
entries when the original RGB data contained these colors we permit
choosing near white/black colors in the cases where this might be
a desirable result as the whitest/blackest colors.
(cherry picked from commit d4387987b5)
The median-cut algorithm to derive a suitable palette for the image
computes each index to be used as the average of colors in a 3d box
in a color space, making the result value drift away from the extremes.
This makes it nigh impossible to achieve pure white or black, even
when the original image contained these colors, like in scans of
printed documents and technical drawings.
We counteract the drift by snapping the whitest color to white and the
blackest color to black if the resulting colors of median-cut are
already sufficiently close to white or black.
(cherry picked from commit 9bb3ff42d7)
layers_opacity_cmd_callback(): get the select_type from
the GVariant instead of using the GVariant as an enum
directly (missed when porting, spotted by Massimo).
Fix the same bug in channels_select_cmd_callback()
and layers_mode_cmd_callback().
(cherry picked from commit 50257e9f7e)
In GimpUnifiedTransfomTool, avoid moving the pivot when
readjusting, and when the transform directions are linked, if the
pivot is locked.
(cherry picked from commit d7c995153d)
... which copies a TransInfo array to the current info array,
possibly with modifications. While the default implementation
simply copies the array as-is, the following commit will override
the function for the Unified Transform tool, to avoid copying the
pivot position when the pivot is locked.
Use the function in GimpTransformGridTool, instead of copying the
array directly, as necessary.
(cherry picked from commit aa1a1f0a0c)
In GimpTransformGridTool, keep the transform-direction chain-button
insensitive while the tool is not active, and always unlink the
button when halting the tool. This avoids the directions from
accidentally being kept linked, resulting in the tool seemingly
having no effect.
(cherry picked from commit 9f6af7dbd3)
For some reason we reverse the channel order when loading/saving a
PSD file. This doesn't seem to be necessary, and leads to a
reversed channel order across GIMP/Photoshop. Simply use the
normal channel order instead.
On 64-bit, all seems fine, but when building to 32-bit (at least Windows
32-bit), G_GUINT64_FORMAT is defined to "%llu" while time_t is a long
int. So it doesn't match and the compiler complains:
> warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'time_t' {aka 'long int'}
Let's cast to (guint64) to make sure the type always match.
(cherry picked from commit 7e7d48a7ac)
Our installer use Msys2 packages when possible. And Msys2 repository
provides version 0.3.9, released on March 2, which contains our patches.
No need for them here anymore, no need to make custom builds.
(cherry picked from commit 0aca033370)
Use the right GtkAdjustment in gimp_scale_entry_log_to_linear().
See merge request !49.
Thanks to MihailZenkov for spotting this!
(cherry picked from commit 5dc1572b01)
When building (at least on 32-bit), fixes this warning:
> app/widgets/gimpdashboard.c:3840:58: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Unsigned long long is specified in the C99 standard to be at least
64-bit. So it's normal that the compiler complains, as a cast from
unsigned long long to a pointer has chances to go very wrong.
Yet gimp_backtrace_get_frame_address() actually returns a guintptr which
is type-compatible with gpointer so let's not give the compiler false
information and just use this type. Then cast it to unsigned long long
just for printing to dashboard log.
(cherry picked from commit 8caef4ea0b)
... when rulers and scrollbars are hidden
In gimp_display_shell_fill(), make sure a size-allocate always
happens for the canvas, even when the rulers and scrollbars are
hidden, so that the pending size_allocate_center_image is handled,
and doesn't block canvas drawing.
(cherry picked from commit 4e560f2ff0)
