Commit-triggered pipelines on `master` branch are apparently canceling
flatpak pipelines even though the flatpak jobs are not even in the
triggered ones.
In any case, these flatpak pipelines are not triggered often (only
through weekly schedule or manually triggered) so there is no need to
have such a flag.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/340147
If you first open a multi page TIFF, exiv2 generates EXIF tags for the
first 3 pages in the form of Exif.Image.<tags>, Exif.Image2.<tags>,
Exif.Image3.<tags>. When exporting with EXIF saving enabled, exiv2 thinks
it needs to save TIFF pages for the EXIF metadata of the second and third
page too. Those pages saved by exiv2 contain only metadata no real image
data and give warnings when loading.
The EXIF tags read from page 2 and 3 are only the basic image specs. We
don't use those, nor do we add tags to it. Until we support handling of
metadata for those pages and exiv2 has better support for all TIFF pages
beyond the first few, I see no reason to save this information.
So for now lets just delete all tags that start with Exif.Image followed
by a number.
On Windows there is a long standing issue in its File Explorer. When
GIMP exported as a multi page (multi-layer) TIFF with thumbnail saving
enabled, then the Windows thumbnailer apparently gets stuck and does not
close the TIFF file when browsing a folder. Because those files are not
closed it is impossible to delete them. This issue has been reported
many times over the years to Microsoft without any reaction.
Investigation showed us that this lock up only happens when we save the
thumbnail as a subifd. To resolve this issue we change this and now let
exiv2 handle our thumbnail saving, just as for other image formats. For
TIFF this means the thumbnail is saved as the second page of a TIFF.
Previous commits have made sure that it is now easier to recognize a TIFF
page as a thumbnail and to make sure we don't load thumbnail TIFF pages.
Since saving as a subifd is what made TIFF thumbnail saving different
from other formats, this commit consists of only removal of code.
TIFF image pages can specify what type of image that page represents.
If the page is marked as FILETYPE_REDUCEDIMAGE we will consider it to be
a thumbnail and filter that out of the list of pages that can be selected
to be loaded.
In addition to that we will try to recognize certain pages as thumbnail
that don't have the subfiletype tag set.
We will consider it a thumbnail if:
- It's the second page
- PhotometricInterpretation is YCbCr
- Compression is old style jpeg
- First page uses a different compression or PhotometricInterpretation
If these conditions are true the page will also be filtered out.
We could consider having an option whether to filter out thumbnail pages.
Since in the situation up until now we also don't load thumbnails, I think
this should be considered as a separate feature.
Since it appeared with GLib 2.68.0, we could not change this until we
bumped the dependency which has only become possible a few days ago
(since Debian testing is our baseline for dependency bumps). Cf.
previous commit.
As this is a drop-in replacement (just a guint parameter changed to
gsize to avoid integer overflow), search-and-replace with:
> sed -i 's/g_memdup\>/g_memdup2/g' `grep -rIl 'g_memdup\>' *`
… followed by a few manual alignment tweaks when necessary.
This gets rid of the many deprecation warnings which we had lately when
building with a recent GLib version.
GLib 2.68.0 was released on 2021-03-18 and has finally been added to
Debian testing (now that the release freeze is over!). So dependency
bumps are slowly going to happen again on the development branch.
Actually Debian testing has even 2.68.4, but it's a bit too recent and
2.68.0 is enough to get rid of some of the deprecation issues.
By default, when on "auto", the update check feature will be set
depending on the OS. In particular, on Windows and macOS, it will be ON,
because these are the 2 OSes which we distribute without an update
channel, hence where people used to have very outdated versions of GIMP.
On Linux, *BSD, and so on, distribution provide updates through package
repositories.
- Migrate "view-rotate-reset" to "view-reset" (there is a
"view-rotate-reset" in GIMP 3, but it will be only for rotate; what
was really doing the same-named action in 2.10 is now what
"view-reset" does).
- Make sure we don't migrate "file-export" from a 2.10 config. From a
2.8 or below, we don't to migrate it (same as for 2.8 to 2.10), but in
a 2.10 config, it is already the same action as the one in GIMP 3.
Action "view-rotate-reset" renamed to "view-reset" (resets both flipping
and rotate). New "view-rotate-reset" and "view-flip-rotate" for
resetting rotation and flipping respectively.
Fix the search for previous folders, which was broken as it was
specifically expecting 1-digit numbers so far.
The differences of the GIMP 3 config import are:
- update sizes and positions in the sessionrc according to the scale
factor, because GTK2 doesn't have scale support. It means that, e.g.
with a 2× display, all sizes and positions in GIMP 2.x must be divided
by 2 (otherwise the first thing many people will get when testing GIMP
3 for the first time is an off-screen window).
Of course, I even wondered if it would not be nice to just drop the
sessionrc altogether and start with a nice blank slate, but then you
also lose the opened dock and their organization and some settings
(such as whether you chose single or multi window mode, etc.).
- scripts/ and plug-ins/ are not imported. Probably makes no sense so
far as they would end up broken (but maybe it's not true for all
script-fu scripts?).
Commit 59f2ba44c7 changed the devel docs to tell that on Linux, just
running the gdb command `continue` is enough to restart the plug-in
process. Maybe it is true on some specific setups, so I leave this part
of the note, but for sure it never worked for me. I may run `continue`
as many times as I want, the process stays stopped until I explicitly
send a SIGCONT signal (our code raises itself a SIGSTOP which requires a
SIGCONT for continuation of the process).
Maybe in some configurations, gdb actually sends a SIGCONT when
`continue` is run but not in others? No idea.
Anyway I add back the part about sending a SIGCONT too, then people can
test and choose which procedure works for them.
Since the recent changes to add template ability, there are just too
many widgets stacked up vertically. Let's use a little better the
horizontal space.
To do this, I moved the preview on the right side of the "Canvas Size"
and "Offset" number fields, and the "Center" button just below it.
libwmf was still relying on a script called freetype-config instead of
using standard pkg-config. It seems it got wiped out in recent freetype2
(or at the very least, this script is not present anymore in freetype2
version 24.0.18 from master runtime of GNOME SDK).
This patch uses pkg-config in libwmf configuration instead.
As I also had some autoheader "missing template" warnings (which were
failing the recreation of config scripts), I add placeholder
descriptions to AC_DEFINE() macros, as this is apparently now mandatory.
Boyuan Yang