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.
setlocale(LC_ALL, "") queries the user locale.
setlocale(LC_ALL, NULL) also queries the locale, but not the user
locale. It actually queries the programs locale, which by default is C.
Otherwise the user would need to have en_US.UTF-8 available no matter
what.
Check that derivates UTF8 of C locale aren't used as well.
Bug: https://bugs.gentoo.org/969468
Fixes: 88261f8b4c
Signed-off-by: Alfred Wingate <parona@protonmail.com>
file with INT16_MIN layer count
In PSD files the layer count is a 16-bit int that can be negative.
A negative value is a flag for transparency.
In our code, after setting the flag, we negate the value. However for
-32768 the minimum possible value, there is not 16-bit positive value,
so the value stays negative. This can cause a heap allocation failure
when we use this value to allocate memory.
To fix this, we check if the value is G_MININT16 and error out in that
case.
This function is counter-productive, since we now want to have both
deprecated and deprecated_since together. But there is no generic
"since version" to be used for such a macro.
So let's just have people explicitly add both variables (and error out
the generation script if they miss any).
