Resolves#13014
In GimpHistogramEditor, pixels and counts are stored
as doubles. We previously converted them into 32bit integers
when displaying the values to the user.
As it is possible for the dimensions of an image to exceed the
limit of a 32bit integer, this could lead to overflow and negative
pixel counts.
This patch switches our display code to use 64bit gsize casts
for conversion to prevent this from happening.
The documentation for gimp_prop_toggle_new ()
had "icon_name" and "label" in the wrong order.
This patch fixes the documentation to be consistent
with the API.
Color profiles were not being correctly connected to
Swatchbooker imported palettes, because the path
was included with the profile name (so a direct comparison
did not match). This patch fixes this by comparing the suffix
instead. It also fixes some minor formatting issues.
Procreate swatches are zipped JSON files.
They contain an object array of HSB
color palette values. Newer versions of the
format also support different color models,
spaces, and color profiles.
This patch adds support for importing the
palette name, colors, and associated color
profile in the original HSB format.
240160f3 added some unintentionally margin-right values
for buttons in GimpSpinScale and the header icons in the
GimpLayerTreeView. This patch adds definitions to those
CSS styles to override the general addition of the 4px
margin-right values.
In GIMP up to 2.10, the default color for the Fog filter
had linear RGB values (240, 180, 70), (#f0b446).
The set_rgba call that's now in Fog treated these normalized
values as sRGB, resulting in another, lighter color (#f8db8e).
Change to recalculated values from the definition at
https://en.wikipedia.org/wiki/SRGB to get the original color
again.
See: #15547
This needs approval from Cannonical and allows migrating app data from
older versions as well writting current app data outside the sandbox.
Closes: #15807 by preloading API-related libraries for 3P plug-ins sake.
This will only work if the .appimage is run normally (without extract), because
when extracted its APPDIR can be placed on dirs with spaces unsupported by LD.
It also requires plug-ins to be built with the Debian used for the AppImage.
But there is nothing new under the sun, this rule is valid for all packages.
When we call (gimp-context-set-defaults) in the
Round Corners script, we reset the background color
in addition to temporarily clearing out the other
context settings. This results in us always using the
default white background color for the "Add background"
toggle.
This patch saves the background color beforehand and
restores it before creating the background layer, so we
still use the user's preferred color for this layer.
Our historical heuristic looking for the main monitor based on the
position of the center point in a widget just won't work on Wayland,
where reported positions are always (0, 0). This is the security policy
for this protocol.
Instead we must now use gdk_display_get_monitor_at_window() which is
meant to do the approximation of determining the monitor a surface is
in, for us.
This is one step of implementing color management for Wayland (#15827),
except we still need the code to get the ICC profile of a monitor (but
now at least, we know which monitor we are on).
Resolves#15833
When we copied images in
gimp_image_duplicate_sample_points (), we only carried
over their X & Y position, not their pick mode.
This patch adds calls to get the original pick mode and
to set it to the new sample point created in the copied
image.
...on start.
Users who open GIMP with images
(such as via the command line or drag & drop)
may not want the Welcome Dialog to
appear over their image.
This patch moves the check for files to be
above the code that loads the Welcome
Dialog, so that we can pass that information
to gimp_update_auto_check ().
If files are being loaded, we don't display
the Welcome Dialog (with the exception
of on first update, so users don't miss the
update information).
There was a report on reddit that the flare files on Windows were
stored with Windows (\r\n) line endings and that gradient flare did
not recognize these flare files.
Since these files are text files there is no reason not to accept
windows line endings. To do this, we adjust the header to not include
the line feed and check for the header as a prefix instead of the
whole line including line ending.
Also adjust saving to add the line feed separately.
If a filter is inactive/invisible, it does not
affect the appearance of the drawable.
Therefore, when merging all active filters,
those filters should not be removed.
This patch adds conditional checks for
gimp_filter_get_active () and does not
remove filters on merge if it returns
FALSE. It also adds sensitivity checks in
the GUI so that the merge down button is
not active if there are no visible filters.
when loading a specially crafted PSD.
After fixing the issue in the previous commit, using the poc from that
issue, a new issue surfaced where the ptr_array used for
img_a->alpha_name did not contain any names. Trying to access the
first index then caused a crash, because apparently that is only
valid if at least one item has been added.
Let's fix this by only creating the ptr_array when we know for sure
that we are going to add an item.
in fread_pascal_string
In plug-ins/file-psd/psd-util.c, the function fread_pascal_string()
allocates a buffer with g_malloc(len) and reads len bytes from the file
into it. The buffer is not null-terminated, but is assumed to be in
later code.
This causes it to read past the end of its allocated region with a
specially crafted PSD, causing a heap-buffer-overflow.
Fix this by alloocating one more byte than its length and set that
to '\0'.
When opening a saved gfig file that came with GIMP, I noticed
several criticals:
GEGL-CRITICAL **: 09:16:16.320: gegl_color_get_format: assertion
'GEGL_IS_COLOR (color)' failed
After that the gfig plug-in crashed.
After examination I noticed that the initial style gets copied. In
the case of the default style this means the source and destination
are the same.
When duplicating our code first removed the GEGL color objects from
the destination style before assigning from the source. But because
they are the same, this leads to invalid colors. Before the change
to GEGL colors they were simple values where reassigning didn't matter,
but here it does.
Since the same function does other assignments with resources that
may cause later issues, let's just return right away if the source
and destination style are the same.
Resolves#15814
As noted by JungWoo Park, since in fread_unicode_string ()
we read in a 32 byte value and then attempt to allocate
double the memory, we run the risk of overflowing and crashing
at g_malloc ().
This patch converts that function to g_try_malloc () and checks
if it returns NULL before going further.
Per user request, this allows you to flip
on-canvas items with the arrow keys when
the Flip tool is active. Left/right arrow keys flip
horizontally, up/down arrow keys flip vertically.
Note that having an active guide highlighted overrides
this distinction - pressing any arrow key will always flip
over the guide, same as with the mouse.
In particular, for indexed images, color choice will happen within the
colormap.
The following uses are made context-aware:
* Test tool options color;
* Fill colors.
These other uses will not be context-aware:
* Padding, quick-mask and padding colors;
* Out-of-gamut colors;
* Generically generated color buttons (e.g. in filter dialogs);
* Foreground selection's mask color;
* Grid colors.
Looking in these tests, most are hard to test with just the API. These
will need to be properly replaced once we'll make use of a UI testing
framework allowing such tests.
Issue #15763 is again mostly false positive crashes of the unit tests
because the code is only partly GIMP code, arranged differently as what
a full GIMP process would actually do.
The new tests just runs on the real GIMP code. Now the difference is
that we don't test the UI by doing this, but this can be debated whether
the previous tests were actually running on the UI themselves (they were
mostly running some core code directly and sometimes activating some
actions or raising dialogs (gimp_test_utils_create_image_from_dialog()),
but again not by actually clicking or hitting keys as a human would do.
It's not proper UI testing (cf. #9339 of #13376 for further discussions
on this topic).
So in the meantime, let's go with this intermediate step. At least now,
such tests would run actual GIMP code and would catch issues which could
really happen in a GIMP process.
