when creating a new image.
We add a new function `gimp_metadata_set_creation_date` to
`libgimpbase/gimpmetadata` to handle setting all relevant
metadata tags.
We add a local function `gimp_image_new_add_creation_metadata` to
add the creation date metadata to relevant functions that create
new images.
We write tags for both the creation date and several modified dates
for IPTC, XMP and Exif metadata. All these use different ways to
express date/time and timezones and I can already see we need to have
another look at other places where we handle modified dates.
This solves the second part of #7287, adding metadata about the
date/time a new image was created.
When starting from an image we created in GIMP, saving/exporting with
metadata and/or thumbnail (thumbnails are part of the exif metadata)
failed, because our metadata was not initialized for newly created
images.
To fix this, create a metadata object in `gimp_create_image`, that way
when creating a new image in the gui, but also when creating an
image programmatically, gets metadata attached at the start.
We need to do that here, because we need to have metadata available
even for images that we import that do not have metadata attached.
A flush happens when closing image displays, and with the idle code, it
means that the actual flush may happen once the image is already freed.
When I was saying that multi-threading is always full of surprises…
It became clear we need a RC3, mainly for 3 reasons (ordered with first
ones being more serious issues) for which I think more testing would be
better:
1. The changes in the image graph, regarding filters (#12614), and
possibly more than I am thinking of doing before RC3.
2. The change in multi-threading code for paint (#11389). I want to be
sure not to create new crashes (multi-threading is always full of
surprises!).
3. The change to a central plug-in API implementation (!2058) and I want
to make sure it doesn't bite us back with more testing (though it is
only for persistent plug-ins so it is fortunately not touching every
plug-in).
The fix is basically to make gimp_projection_flush() thread-safe, so
that it can be called from any thread.
The actual rendering was actually already run in the main thread since
it was in an idle function, but update_region could be touched both from
the main thread and another thread (e.g. the "paint" thread). An
alternative could have been to put some mutex to protect usage, but then
I realized that iter variable was also to be protected, and there was
some code where I am unsure if we had to protect larger parts of code
(in particular with gimp_projection_projectable_bounds_changed() which
was touching update region through gimp_projection_chunk_render_stop()
then directly). The nice headaches of multi-threading!
Moving the whole actual logic of gimp_projection_flush() in the main
thread seems much more robust and maintainable.
xgettext changed its default behavior since version 0.23 regarding
escaping of special characters into XML entities. Now we need to change
the gt:escapeRule value, differently depending on xgettext version (it
will fail in both cases with the wrong value, except the "wrong" value
is the opposite before and after).
This reverts commit 9b94e347bc.
I leave a comment though, because we are not 100% sure that the issue is
gone. In fact, the upstream report is still opened.
The good point is that on stable code, we only debug crashes by default,
while the specific hang we had was happening with debugging metadata
warnings. So hopefully we won't have random people reporting GIMP
hanging (only people explicitly trying to help debugging GIMP).
If the generated `gimp_welcome_dialog_n_items` variable
is 0, there are no release notes to show (likely because
this is a development version). Therefore, we don't create
the Release Notes tab in the Welcome Dialogue.
...trying to get index.
When changing images or detaching a Colormap dockable,
we may temporarily not have a selection when the GUI
actions update. This patch adds a check to confirm we
have a valid selection before trying to get an index
from it.
We validate arguments for a reason. This special flag must only be used
in special cases (when it's harder/not possible or not implemented yet
to validate properly).
In fact #12039 would have been much simpler to diagnose and debug if
this flag had not been there from the start, because we would have had
an error earlier, on core side, which we could have traced back much
more simply!
We had special code to pass around a special config object for some
filters but it was just looking if this first "non-standard" (after run
mode, image, drawables…) was an object and inserting the settings
object, which turns out to be NULL in most case (except for these
special filters from the filters_settings_actions list).
This is not right, first because we may override the default value in
such case, second because, even if this arg may be overrided later
depending on run mode, it is possible that this random other
(non-config) argument may not even allow NULL to begin with. This was
what was happening in #12039.
GIMP have its own hicolor in 'share/gimp/*/icons/hicolor' since 2.99.2.
Removing that package made no difference to the resulting AppImage and
I could not find any indication on our tracker about its necessity.
Committing every filter one by one had the same drawback as in #12614,
and as destructive effects in general: you have to go back to source
storage precision after every layer. This really shows its limits when
this precision is low (8-bit per component) and/or when the TRC loses
even more data (linear TRC in 8-bit is usually not a good idea) as shown
in the report.
So instead, use the render of the last active filter directly and switch
the drawable's buffer with it.
While it's normal to be limited to the storage precision at drawable
level, we want to have as high precision as possible during processing.
Two pieces of code were problematic in this regard:
1. GimpApplicator had a "gegl:convert-format" node which was converting
back to storage format after every effect. Instead only set this node
after the last effect.
2. "gimp:mask-components" operation was working with the input format.
Let's change this to work with the higher precision when comparing
input and aux format (typically when aux was the output of a previous
filter, now that we didn't convert format back to storage precision,
the aux precision may be bigger).
When creating a color widget in GimpProcedureDialog, we
were not taking into account whether the parameter's
has_alpha boolean was set to FALSE. As a result, all color
widgets allowed for transparency.
This patch checks if the GimpColor's GParamSpec has_alpha value
is FALSE, and if so, sets the color widget's type to
GIMP_COLOR_AREA_FLAT to enforce no transparency for that color.
Resolves#12719 and #12721
In b78f3dad, we assume that a filter is being created for a
single operation. However, certain tools like Bucket Fill might
pass a GEGL Graph node instead. This causes the call to
gegl_node_get_gegl_operation () to return NULL, which then
crashes when we attempt to get the Operation Class.
This path verifies that we have a single operation before
attempting to go further with getting its class.
Fixes: #11756
Context: Debian Bookworm only have GCC that links to MSVCRT C library.
Actually, crossroads is failing on our CI probably due to GCC-MSVCRT.
On Debian, there is GCC-UCRT too but it is marked as Experimental and
crossroad does not support it nor Clang-UCRT yet: GNOME/gimp!1860.
Some people reported crossroad working with GCC-MSVCRT in Fedora but
adding a brand new pipeline would be at least suboptimal to mantain.
So, we are temporarely moving from crossroad to quasi-msys2 project which
have UCRT support for both GCC and Clang (it takes compiler resources from
MSYS2). The compilers itself we will take from Debian Testing for parity
(they are standard GCC and Clang with proper CFLAGS set by quasi-msys2).
We may go back to Crossroad when it has UCRT support like quasi-msys2.
We always save the filter name in XCFs,
even if the user did not intentionally set
it. This means that "default" names like
Gaussian Blur are not translated when
saved and loaded in XCFs.
This patch adds a new property,
"custom-name", to GimpDrawableFilter.
It is FALSE by default, and only set to
TRUE if the user provides a custom filter
name (currently only possible in the
public filter API). Based off this value,
we either use the saved filter name or
get it from the operation when saving and
loading a filter from the XCF.
Resolves#12682
Some system themes add a gradient background-image to
text input and toggle widgets. On dark theme, this can
make the text unreadable if the background-image is a similar
color. This patch defines the background-image as none, to
prevent the system theme from leaking in.
What it was doing was casting the input buffer to another TRC, basically
pretending the data was what it was not. In particular, it was casting
linear input buffers to non-linear and all other TRCs to linear.
As was noted in #1958, this was in fact a useful trick, yet it's still a
trick. Basically when it's needed, it's either:
1. because the operation implementation does not work in the technically
correct space. Then the operation code should be fixed;
2. or because several work TRC are valid, then an option should be
proposed by the operation;
3. or for artistic reasons, which people are free to implement as
plug-ins or third-party filters, but it should not be a core GIMP
feature.
Therefore for most cases where it felt needed, the real solution will be
to improve the operations' implementations.
These were missing help ids and don't have tooltips either, while some
of these actions may not be clear to end users what they do.
This will allow us to have context sensitive help about these commands
in the manual.
This regression was added with MR !1551 (commit 7ccfad1716).
Localization was still working fine on the main processus, which made
the problem less obvious. But every plug-in would output such an error
on start:
> (border-average:257681): Gtk-WARNING **: 17:22:17.640: Locale not supported by C library.
> Using the fallback 'C' locale.
And the localization was indeed not working.
Apparently having a properly qualified locale, with both region and
encoding (e.g. "fr_FR.UTF-8") is fine, but any other contents was
breaking the whole locale.
Since it seems that this issue doesn't happen on Windows at all, let's
just not set LANG, except on Windows.
when loading an exr image.
While looking at the openexr fuzzed images I noticed we do not check
whether height or width are larger than our maximum.
Although this was caught in libgimp when trying to create the image,
let's add checks in the exr plug-in itself.
the offset to the dest buffer passed to the line-reading functions
wasn't counting bytes but items/values, which was slightly confusing.
Changed to not pass the offset at all, but rather a pointer to the
start of a line inside the buffer.
Also made rowstride count bytes, not values.
Made dest and rowstride local vars, as they are not used anywhere else.
