As suggested by pippin, it would at least prevent loading XCF which
would override local files using default GEGL operations. Normally these
ops which writes to file cannot be created through the GUI, but a XCF
using one such op could easily be constructed.
Of course, this doesn't block third-party ops doing similar things
without being sink operation subclasses.
E.g. changing from non-linear to linear without bit-depth change would
trigger a CRITICAL on mask conversion, because masks are always linear
anyway. Only the bit-depth change should trigger a conversion.
Rather than showing actions as active when they'll just be no-op, make
these inactive.
There are more to fix this way, but these 2 had been really annoying me
for some time because they are very often run.
On generating our PDB files, we were
getting warnings about uninitialized strings.
This is because descriptions and authors
had been left off three .pdb files. Adding
these in resolved the warnings.
A new PDB author entry was also added
for Idriss Fekir.
The IPTC TimeCreated tag does not allow fractions of a second, while
Xmp.Photoshop.DateCreated (which includes the time) does allow this.
In our metadata editor we base our date/time on the last value and then
synchronize it with the IPTC date and time values.
While doing that, we did not check if the seconds had a fractional part.
To fix this we first check for the presence of a fraction by checking
for a dot in the time string.
Complicating factor is that a timezone difference may follow that,
which we want to keep if present. So we check for that too and
concatenate the parts we want.
These function names look like they should be applied to a
GimpPaletteEntry, which is a type which doesn't exist in libgimp. This
naming is much more appropriate.
Fix a generic case when gimp_window_set_transient() is called on an
already mapped window: the handle argument was missing.
The part in bmp-export though, in fact, I am still a bit at a loss.
Somehow calling gimp_window_set_transient() was making the dialog not
showing up at all, yet kinda blocking the bmp plug-in (waiting for a
response to the non-displayed dialog) and various features in the main
GIMP GUI too.
Calling gtk_widget_show() first, before setting transient was enough to
make the dialog finally work as it should, but this is really not ideal.
I compared to other cases in other plug-ins where the set_transient()
function was called before the dialog was shown and it is working fine.
I just cannot find the proper reason. So this will do for now.
They are now replaced by the more generic gimp_palette_[gs]et_colormap(),
hence making less of a particular concept of "image colormap". It's just
a palette attached to the image (and restricted to the image format).
When I see that we are just using R'G'B' format with no space
everywhere, I'm pretty sure some of this code must be wrong (even though
for some formats, maybe only sRGB is supported, I am guessing that for
some others, the palette may be in specific color spaces).
This will have to be improved with time.
In particular, palette's colors will want to be shown in their own space
(which may in fact be the image's space, for indexed image's colormap;
or in various spaces for named palettes).
Also make sure gimp_data_copy() also copies the proper palette format
restriction and apply it when necessary (e.g. setting the stored
colormap which is done when popping an image undo).
Otherwise we were losing format/space information, which was corrupting
color space when undoing then redoing.
It was an equality because I think the conversion from palette format to
"RGBA float" should go through the exact same babl code path, however it
is done in the API. And that is the case on my machine where I get
indeed perfect equality. But apparently not on the CI.
Though I guess investigating further would not be a bad idea, let's
consider this a minor issue (as a general rule, comparing float with
epsilon is still a recommended software usage), and just add a comment.
If execinfo.h was not found, do not try to compile gimpbacktrace-linux.c
because the backtrace() API is not optional there.
Also I'm further improving the meson summary, regarding "Dashboard
Backtraces". Rather than just yes/no to say if the traces are detailed,
let's go for finer-grained state, saying if the traces are completely
deactivated ("no", e.g. when execinfo.h is not found), or "rough" (when
libunwind and libbacktrace are not found) or "partially detailed" (one
of these is not found) and finally "detailed".
Also add info on missing dependency between parentheses to help
packagers find the proper dependencies to get to the "detailed" state.
GBytes are a bit annoying to handle, so I'm renaming the PDB procedure
to a private _gimp_palette_get_bytes() instead, and making a wrapper
function which returns a C array and both the number of colors or number
of bytes. The latter is needed for introspection (otherwise the binding
can't know the size of the C array), but for the C API, both these
returned integers can be considered redundant (since one can be computed
from the oher), so only one at a time is mandatory.
When we want to set a full palette based on an existing one, no need to
request the full colormap from core to libgimp then back. Just set the
palette which is nothing more than an empty shell around a resource ID.
I had this case with the palette of an indexed image which had its own
reference to the image. So the image would never be freed until the
palette is freed, while the palette is freed in GimpImage's dispose()
code.
Make this a weak reference from GimpData instead.
This is not necessarily a core bug, so I can't put this message as a
WARNING or CRITICAL. It may just be a plug-in which left some image
over. Nevertheless it is still useful information for plug-in
developers, same as it can also help core developers to discover actual
core bugs (see next commit).
I had the case when gimp_exit_idle_cleanup_stray_images() would clean up
some images on exit, apparently after the GtkApplication is itself
already gone.
We have a bunch of special-casing format passing through the PDB, but
either we were only passing the encoding, or else we were reconstructing
the full format through private intermediate functions. In the
space-invasion world, this is not right. Let's have a proper "format"
type for PDB which does all the relevant data-passing for us, once and
for all!
Note that I am creating a wrapper boxed type GimpBablFormat whose only
goal is to have recognizable GValue since Babl types don't have GType-s.
Moreover I'm not using the GeglParamSpecFormat either, because it just
uses pointers which again are a bit annoying in our various PDB code.
Having a simple boxed arg is better.
Since I use the Python console a lot myself to test GIMP API, the
ability to recall previously ran commands is extremely useful. Let's
just add support for this as an AUX argument. This was already done in
the Script-fu console, now in the Python console too!
gimp_scanner_parse_string() transforms the empty string into NULL, which
might be what we want elsewhere, but definitely not for GStrv since NULL
is the end flag for the string array.
A path on Windows contains backslashes, which got interpreted as
escape sequences in script-fu when selecting a filename by the call
to g_string_append_printf.
This caused failures in e.g. Stencil Chrome after selecting an
environment map image.
Use script_fu_strescape to escape the filepath, so that we correctly
interpret the Windows path.
See also
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1851#note_2225989
febb2126 was proposed temporarely while we had hope of having a fix.
Now, we have !1860 (apparently 99% done) but the main maintainer of
crossbuilds refused to look at it because he is focused on core code
until 3.0 so, with this timeframe, the commit lost its reason to exist.
So, to avoid keeping runners work unnecessarelly with abandoned jobs,
let's not trigger them ('when: never') as I proposed on IRC months ago.
