After the change that allows multiple layers to be selected exporting to
a pattern fails.
Patch this as suggested by Lloyd Konneker by doing the same as for brushes:
do not allow multiple layers, instead only send the first drawable.
On Windows loading metadata from images with non ASCII characters in their
path failed. Part of the fix is in gexiv2 that now converts the path from
utf-8 to utf-16 on Windows.
However we were still sending a localized path to gexiv2 where it was
expecting utf-8. This caused the conversion and thus loading of metadata
to fail. Fix is to remove the special handling for Windows and use the
utf-8 filename.
Due to differences between Windows and most other platforms Ghostscript
didn't correctly load files with special characters on Windows.
First we needed to make sure that the filenames we use are in utf-8
format and then tell gsapi that we use utf8 encoding.
When exporting to bmp using a script or plug-in we could not set the
parameters use-rle, write-color-space-info, and rgb-format when used
non-interactively.
This is discussed in issue #491. The patch there does not work for master,
so I came up with this.
When exporting a C source file with runtime length encoding, the
C-string's array size does not accomodate for the null byte. However,
GIMP accomodates for the NULL byte in it's NON-RLE export, suggesting
that this has been a mere oversight for RLE.
This can cause at the worst a compile-time error and at least a warning
from the compiler.
I somewhat bisected GEGL commits between 0.4.20 and 0.4.24 and found
that the one that introduced the env var GEGL_OPERATION_INIT_OUTPUT is
the first showing the problem.
Reviewer (Jehan) note: so it would be commit 6e9610e65c on GEGL repo.
This fix makes sense as it means that since this commit, the output
buffer could have random values. It's not a problem for any operation
where we fill every value, but I guess it's not the case for
"gimp:cage-coef-calc" which was likely relying on the old behavior of
being 0-initialized.
Reviewer comment (Jehan): we have used this patch successfully on our
installers since start of 2021 (see commit b4d665d of our gtk-osx fork)
and it really improved the situation. I only fixed minor coding style
stuff in the patch.
Looking at what it does, I guess it is not ideal long-term if related to
10-bit display (as I understand from the comment), which a graphics app
would want to support properly. But for now, this is better than
extra-slow display until we get macOS developers able to look at this
more in depth in the future (I don't think that our dependencies are
really ready yet for 10-bit display support anyway, though I may be
wrong).
Some other forums seem to say it comes from macOS invalidating now more
than it should (i.e. the whole area instead of only the changed area)
and this NSViewUsesAutomaticLayerBackingStores flag would disable this
behavior. It might be one of these reasons, the other or both. This is
anyway a good first start for future contributors.
As discussed in !455: remove duplicate testing, testing header and
testing the library are a same test in one (for instance we don't want
to get into weird cases where the lib is found but not the header; this
updated test takes such inconsistencies into account). Also it's better
to have all dependency tests together in the root meson file.
Finally adding some comments to make this all more understandable for
anyone looking at this in the future.
g_alloca() is unadvised. Even though it might be more efficient in some
specific cases, it is pretty subject to stack overflow when a lot of
memory is requested.
Let's allocate dynamic memory instead. To avoid doing it too much, let's
just reuse the same pointer especially since region of interest will
usually be the same size when iterating a buffer, except for border
ones (which would usually be smaller, so we can use the same allocated
buffer again). I still make size checks, just in case.
Thanks to Massimo Valentini for finding these.
Fixes:
> GLib-GObject-CRITICAL **: 13:21:53.256: Object 0x5485140 of type GimpLineArt not finalized correctly.
> GLib-GObject-CRITICAL **: 13:21:57.472: Object 0x231f520 of type GimpExtension not finalized correctly.
Outputted when glib is built with -Dglib_debug=enabled and GIMP is run
with GOBJECT_DEBUG=objects.
For 1-bit BMP export we did not show the save dialog, making it
impossible to change settings interactively.
We enable the save dialog for 1-bit too, making sure to disable RLE, which
is not available for 1-bit.
In addition, also set the RLE config option to false for all cases where
it can't be used.
… GimpUi.ProcedureDialog.new()
The old way is still working and acceptable as far as I am concerned.
Just switching to the recommended (by upstream) syntax to show it works
as expected and as a good example of code.
It is now discouraged to create constructor-type _new() functions with
custom code, which would make them behave differently that simply
calling g_object_new() with the GType and relevant properties. The main
reason is that some bindings would create objects with g_object_new() so
it should create expected code too.
See: https://gi.readthedocs.io/en/latest/writingbindableapis.html#custom-code-in-constructors
Here it was complicated for a few reasons:
- We hack "title" property to use the procedure's menu label by default
(without the mnemonic). For this, I overrode the GtkWindow property.
- We want "use-header-bar" to follow the application general settings by
default. Since it is a CONSTRUCT_ONLY property, g_object_set() is not
possible in _init() and _constructed(). Instead I had to override the
constructor() method to set this at construction time (yet still allow
API users to override this with the property at creation).
- Similarly, "help-func" is a CONSTRUCT_ONLY property, so I used the
same trick.
- As for "help-id", I now just set it in _constructed(). This was the
easy one.
All objects of subclass GtkWindow are special as they are actually owned
by GTK which keeps a list of all top-level windows. So we cannot
actually give ownership to the caller. With GObject Introspection in
particular, it will mean a double-free of the dialog object (by GTK,
then by the GI layer).
See also gobject-introspection#394.
As explained in GtkSizeGroup docs, all objects inside a size group holds
a reference to it. So once we destroy the last object inside these, it
will be freed too and we should drop the initial reference after adding
the objects.
Only the main size group reference is kept until the end, because we are
adding and removing objects from it regularly, so it is possible that it
is empty again at some intermediary states. Yet we don't want to free it
when this happens.
I completely forgot that since the installer is built on a Windows
runner, I cannot expect a standard Linux shell syntax.
As a consequence, commit de9a171a19 broke the "win-installer-nightly"
job with the following error:
> The token '&&' is not a valid statement separator in this version.
Rather than trying to find the equivalent command to run on powershell
or whatever, let's just compute the checksum at the end of our installer
creation script.
After updating a keyboard shortcut in the Configure Keyboard Shortcuts
Dialog, the section containing the changed shortcut disappeared.
Apparently a changed shortcut makes its parent invisible so we make the
parent visible again.
We also store a text version of the selected path in the tree to the
shortcut and then use that to restore the path after making the parent
visible again.
On most keyboards the [ and ] keys are shared with { and }. Which means
that if you press Shift+[ you get {. We were using this key combination
to increase the tool's size by 10 and the other to decrease it by 10.
However, on all keyboards where these keys share the same physical spot
on the keyboard, this wasn't working.
So, let's change the actual keys to do this to { and }.
Somehow the test part of the flatpak job stopped working. The last
instance which worked was 3 weeks ago, but after a lot of debugging I
realized that it is not because of any code change on our side. The
exact same commit which worked 3 weeks ago won't anymore!
The standalone bundle is actually built and works fine when tested
independently. What fails is the `meson test` inside the flatpak
environment. Somehow when GIMP is rebuilt inside the test flatpak
environment, it doesn't build the plug-ins yet one of our tests
(save-and-export) requires plug-ins to open some file formats. Note that
I double-checked, the plug-ins were well built and loading any format
works fine in the standalone flatpak, just not in this specific step.
I am completely unsure what broke, yet it is apparently outside GIMP
code. So for now, I just copy-paste the whole flatpak job which we were
including from another repository and remove the `meson test` part.
Our plug-in was not correctly handling DICOM images that use big endian
transfer syntax, which is deprecated.
We add support for that here, add a few g_debug statements to make future
debugging easier, and also return an error when we encounter a transfer
syntax that we can't handle instead of blindly continuing.
Synced from the beta flatpak. The previous manifest rules were building
fine on Flathub build servers, but not on GNOME CI ones. It resulted in
a bunch of "ISO C++17" errors when building ilmbase.
Maybe just restricting to C++14 through build fine would have been fine,
but anyway let's also update the dependencies in the same time as we
were outdated.
As per state in the wip/release/2-99-8 branch of the beta flatpak.
In particular, we update some dependencies (poppler, ghostscript and
SuiteSparse).
It should also fix the master flatpak build which seemed to fail on
downloading SuiteSparse sources. Since their upstream moved their
tarballs to be downloaded from Github, it should take care of this issue
by side effect.
… source colors
Reviewer's (Jehan) note: a git blame shows this is a clear bug
introduced in commit 9d19bf2a3e, which was a cleanup patch, and the
BOUNDS() macro was not doing exactly the same thing as the code before
the change.
The MSYS2 package got recently bumped from 3.8 to 3.9.6.
At first I wanted to update our packaging and installer scripts to be
more generic using glob patterns (so that they should work now and
should continue to work even if bumping to a higher minor version in the
future). Unfortunately this would work for `package-gimp-msys2.sh` but
in `files.isi`, it would only work for `libpython3.*.dll`, not for the
python3.9/ folder. InnoSetup apparently doesn't support using a folder
as source (or maybe just a folder with glob like `python3.*`) as it
resulted in a "No files found matching" error.
So leave everything with the accurate version (because anyway it's much
better to get an early failure than only at the very last step).
Same as MSYS2, add a patch to fix keyboard input when using IMEs (which
should hopefully fix#1603). Note that this patch should be in the next
release.
Also remove the Windows Pointer Input Stack support as it is in 3.24.30.
Finally apply the patch from gtk!3661 for testing (instead of the patch
from gtk!3275), as it is supposed to fix#5475. This is the reason why
we still build our own GTK3.
Commit 8025962a20 was meant to make the icon code work on relocatable
builds, yet I realize that the gdk_pixbuf_new_from_file() calls were
still using the DATAROOTDIR build-time macro. I had forgotten to update
these.
Also update a bit the error handling by adding a GError (for more
debugging info) and a newline for pretty-printing.
Jacob Boerema