This functions has 2 `(out) (array)` arguments, where the array length
is defined by the return value. This can't be expressed in GIR
annotations unfortunately, so just add it as another `(out)` argument.
Also, by default `(out)` args are assumed to be `(transfer full)`, while
these were actually `(transfer container)`.
This proved to be both an import and export issue.
Our import set expected format as RGB, causing garbled image output.
Our export for indexed images converted to grayscale first, although the
palette was correctly saved. This caused wrong palette indexes on import.
For indexed images, on import, we request the actual indexed format after
creating the layer with gimp_drawable_get_format, which gives us a correct
indexed Babl format.
Also added logic for indexed with alpha, although I have no sample images
to test this.
For indexed images on export we do the same: use gimp_drawable_get_format
to get an actual indexed Babl format.
In some conditions, and only with some installations, the called GDB
ends up hanging and never returning. Worse, even if you use non-blocking
functions such as poll() or select() with a timeout, in order to wait
for the debugger output, these block anyway and never return.
We are currently unsure what exactly causes such problem, but not using
the thread command in gdb avoids it for now.
This is a bit of a regression, though most of the time anyway the useful
traces are the main thread ones (I think ever since I implemented this,
there must not have been more than 2 or 3 cases where we actually needed
the secondary traces). So it's acceptable, at least for now.
Otherwise if we add a NUL byte after the last byte, we might right past
the allocated memory. Thanks to Massimo for reporting this error raised
by Address Sanitizer and valgrind (cf. #7539).
In cases where the whole EXIF MakerNote is invalid we still load that
MakerNote data and export it too, causing partial invalid EXIF metadata.
We don't need to explicitly save Exif.Photo.MakerNote at all, because
as soon as we try to save a brand specific tag exiv2 will create that
MakerNote tag itself.
So from now we don't save the MakerNote but only the tags that go in it.
In issues like #2159 where exiv2 doesn't parse all tags inside certain
brand specific MakerNotes correctly, we will still export invalid EXIF.
That is an exiv2 issue that we can't do much about unless we remove all
MakerNote metadata including those that we can read, which doesn't seem
like a good idea at all.
The GtkContainer::child signal is deprecated and it's write-only,
thus the notify::child signal won't work.
Use the GtkContainer::add signal instead.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/2928
Not sure why but adding a handler to the "expose-event" signal of
GimpDisplayShell (similarly to how we do it in master branch on "draw")
just didn't work. But it works on the already existing signal handling
on the canvas instead (which actually is not a bad deal, as we also
remove the coordinates translation so maybe we should test this on
`master` too).
Note: why we are backporting all this logics to gimp-2-10 is because
changes in macOS BigSur broke the selection's marching ants the same way
they broke on Wayland and it was confirmed this fix worked for BigSur as
well, at least on the dev builds.
It is unnecessary to backport for Wayland (because GIMP 2.10 is based on
GTK2 which anyway works only through XWayland, hence doesn't have the
issue), we do it only for macOS BigSur (and further). Well at least the
fix will hopefully work on the stable branch, because I cannot test
myself.
See issue #5952.
(cherry picked from commit 6be014fc59)
Cherry-pick note: it was initially only for gimp-2-10 but actually also
works fine on the GTK3 branch and fixes some selection coordinates issue
when rotating the canvas.
Although there was code to load 32-bit per channel psd images. It is
unlikely that it ever worked, because:
- We tried to load them as u32 instead of float.
- While we did some decoding of the zip predictor data, for float values
we also need to restore the byte order from 111222333 to 123123123.
- We did the endian conversion first while it should be done on the
restored values.
With these things fixed I can load the few samples I have.
Over the last few years, we seem to have been in agreement that .ui
files are not so desirable anymore.
For plug-ins, they are completely deprecated in favor of our much nicer
dialog generation API from properties (the metadata plug-in(s) are the
only ones which still have .ui files but we plan to get rid of these
eventually).
For core code even, we also prefer to generate GUI when we can (as we do
for GEGL ops, for symmetries and other places).
GtkBuilder files actually make for more complicated code, imbricated in
both the C code and .ui files, more bug-prone too and we don't seem to
gain anything from the additional complexity.
So let's get rid of this dev guide.
Fix as suggested by Massimo with formatting adjustments by me.
The use of gulong and glong is not cross platform safe: on Windows it is
32-bit and on most other platforms 64-bit.
Let's use guint64 and gint64 instead.
This tool seems like a mess with various implementations (maybe
distributions patch it?). I'm trying to tweak the script so that it
works at least on the Debian testing/bookworm CI and on my Fedora 33
desktop (and hopefully on more, if not all distribs).
Note that I first thought to use the full option name (`--auto-display`)
but I just got the same error again. It seems xvfb-run from Debian
bookworm just doesn't have this option, and only the older option
--auto-servernum (which is said to be deprecated in favor of
--auto-display in Fedora's xvfb-run for instance, but apparently not on
Debian). At least this works on all distributions (or so it would seem).
Fixes:
> xvfb-run: invalid option -- 'd'
The [[ ]] is not POSIX, hence less portable.
I see our `ninja test` calls in Gitlab CI output a:
> /builds/GNOME/gimp/build/meson/run_test_env.sh: 7: [[: not found
(though it doesn't break the tests)
The `env` option is new (from meson 0.57.0), yet we depend on meson
0.50.0 and bumping the meson requirement is not a possibility (we have
bad experience when we did this for babl).
Instead, implement the new option usage and a workaround which would
work also with older meson.
I could have implemented only the workaround, but it's also nice to
write down the better syntax so that when we actually bump meson
requirement, getting rid of the workaround will just be a matter of
hitting delete and done. Though it also means we must keep both if/else
blocks in sync, so it has its drawbacks.
See the discussion in !506.
Due to starting with the highest index we were referencing layer data
out of bounds.
We need to decrease i with 1 before using it as index into the channel data
for the correct layer.
This caused a crash when exporting multi layer images.
psd-save was using a separate define for enabling debugging. Let's just
use the one define from psd.h.
IFDBG -> IFDBG(1)
IF_DEEP_DBG -> IFDBG(3)
Besides changing the define in psd-save we also change all the printf
statements used for debug output to g_debug. This allows us to view/hide
the debug output.
Matej Urbančič