Something I wanted to implement for a long time and today I finally took
the time after I had one more annoying case where I had to merge all
groups for exporting then undo for saving!
Now this won't be needed anymore as the plug-in will allow to export
only as pages any first-level layers (groups included, so you could
gather your page compositions in root layer groups). For me, it's the
only way I use this when making/editing PDFs with GIMP, but maybe some
people would still want GIMP to crawl into groups and subgroups and
export layers individually. That's why I make it an option, defaulting
at TRUE.
Note that I didn't port "file-pdf-save-multi" at this point, though I
did move to using GimpProcedureConfig instead of GimpValueArray
everywhere.
In any case, that's a lot of code removal and simplification already,
though some part of this plug-in is still a bit ugly.
We also get proper config storing between sessions now.
As for metadata, it unfortunately doesn't look like Exiv2 has PDF
support, so I didn't add metadata settings.
… gimp_procedure_config_save_metadata().
If you use gimp_procedure_config_save_metadata() or
gimp_procedure_config_end_export(), you don't really control the flags
and let the GimpProcedure API make somes choices for you, based on
various assumptions. One of them is that the procedure has specific
properties (named "save-*", either created manually or with the various
gimp_save_procedure_set_support_*() functions). So if you don't have
them, we should assume this format doesn't handle a given metadata
format and deactivate it.
For plug-ins with a different/specific logic, they are expected not to
use these helper functions. They would likely call lower level functions
such as gimp_image_metadata_save_finish() or the newer
gimp_image_metadata_save_filter(), where you control the metadata flags.
The dl*() functions are in libc directly. This probably applies to all
*BSD too. And from what I read, it should even apply to macOS, even
though a libdl is present there (is it bogus?).
So let's make the libdl check proper by only make it mandatory on Linux
(on Windows it was already unchecked too).
Fix the Linux Input test to correctly only depend on whether or not the
header is present. Having X11 target is not enough (e.g. it breaks the
build for NetBSD and probably on all BSDs).
This file was just moved as content/core/specifications/locks.md in the
pat/bootstrap branch of the gimp-web-devel repository.
This branch will soon be merged and become our new website. Removing the
now duplicate in our source repo.
- Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated
HTML, and not an absolute path taken from build dir (otherwise this
would break, for installed docs, but also for the tarball and the
developer website!).
- Also use either gimp-logo.png or gimp-devel-logo.png depending on
whether we are on a stable or unstable branch.
- Install these in images/ inside the GIMP docs folder, which
corresponds to the relative path given to GIMP_LOGO_PATH.
- The installed root dir will be $datadir/doc/gimp-2.99/, e.g.
/usr/share/doc/gimp-2.99/
- Inside this folder, the library references will be in libgimp-3.0/ and
libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that
the root dir uses the application version (2.99) whereas the library
folder use the API versions. These are different in development phase.
- Archive the gi-docgen installed files, not taken from the build dir,
to avoid packaging temp files, such as the .toml files. Note that
`g-ir-docs` files are still taken from the build dir, as we don't
install them yet.
- Finally package all this in a directory before archiving in a tar.xz,
named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside
gimp-api-docs-2.99.13.tar.xz).
We were using GIMP_UNSTABLE extensively to differentiate development
from stable code. But there is actually another level of development
code. Basically GIMP_UNSTABLE tells you are on the development branch,
e.g. for current branches, that you are on 2.99.* versions (vs. 2.10).
This depends on the minor version oddness.
GIMP_RELEASE will tell you if it's a release or a in-between-releases
code. This works with the micro version which must be even on release.
Any odd number means you are basically using random git code.
There can be any combination of GIMP_RELEASE and GIMP_UNSTABLE. For
instance 2.99.12 is a release of the unstable branch, whereas 2.10.33 is
development code of the stable branch.
I use this first in the update code as we were using GIMP_UNSTABLE for
both concepts but it made it harder to test. Now:
* GIMP_DEV_VERSIONS_JSON environment variable is only available on
development code, not on release (whether stable or unstable).
* The weekly check limitation is also only for releases (dev code just
check at every startup to quickly detect issues and regressions).
* Whether to look on testing website or public website json file depends
on the code being a release or not.
* Finally only whether to check "DEVELOPMENT" or "STABLE" sections in
the json file depends on whether we are on stable or unstable
branches.
This was not working due to a missing port in glib.
Potentially could be contributed upstream to GLib.
(cherry picked from commit b391f9f5c8)
Conflicts fixed:
app/gimp-update.c
Fixes:
> gcc: error: unrecognized command-line options '-mmx'; did you mean '-mmmx'?
> gcc: error: unrecognized command-line options '-sse'; did you mean '-msse'?
This is shown in the About dialog when a new version is available, but
also in the debug dialog (also when a new version is available).
Of course, for stable versions, we should still show the main download
page (which I double-checked current code does).
This meson warning was only showing when configuring a cross-compilation
project.
Fixes:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': meson.has_exe_wrapper. use meson.can_run_host_binaries instead.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
For meson, I want to be particularly careful and not follow the "Debian
testing" rule as it bit us by the past for babl.
But this bump is probably OK:
* Debian stable has meson 0.56.2.
* meson 0.56.0 was released on 2020-10-30.
* GIMP 2.99 is a dev branch with no end release date yet.
This should also fix this warning at configuration time:
> WARNING: Project specifies a minimum meson_version '>=0.53.0' but uses features which were added in newer versions:
> * 0.55.0: {'Calling "add_dist_script" with File, CustomTarget, Index of CustomTarget, Executable, or ExternalProgram'}
We missed it until now because it was only happening with tarball builds
where gitversion_h could be a files() object, unlike in git builds.
GIMP tried to open webp files as ani (animated cursor) files. The reason
for this is that for ani we had set the file magic as the first 4 bytes
should be RIFF.
However, RIFF is a container format, used by many different file formats,
among which is also webp.
This means that checking for RIFF is not specific enough.
Based on the info on http://fileformats.archiveteam.org/wiki/ANI
we will check the 4 bytes starting at offset 8 for ACON, which is
apparently the identifying part for animated icons.
Due to a typo in the config property "default-delay", loading of that
option and the ones after it, failed.
Because of this, default-chunks had an invalid value, which made our
export fail. After correcting the typo the export succeeds.
- Setting an exec_dir variable is an error. As meson docs says, if
relative, it is installed relatively to prefix anyway: "If this is a
relative path, it is assumed to be relative to the prefix."
On the other hand, it would make problems if someone tried to set an
absolute bindir.
Moreover it is a lot clearer now. When we want to install in the
binary directory unconditionally, then get_option('bindir') is the
meson way, hence the way to go.
- On the other hand, the `gimp-debug-tool` is installed either in bindir
for Windows or macOS and libexecdir for all other platforms, at least
that's how it's set in the autotools build. So let's keep both builds
consistent.
- Make a hopefully clearer description for enable-default-bin option.
Let's clarify this is just about creating unversionning links pointing
to versionned files.
- Adding an item in the "Optional Features" part of the summary listing
during meson configure, for better discovery.
For the ".exe" extension on Windows, I wished we had an $(EXEEXT)
equivalent on meson rather than trying to set it ourselves (are there
other platforms where we must set a different extension?). But I could
not find any.
and import as inches
When GIMP's display unit was mm, our PSD export converted the X and Y
resolution as if a conversion from mm to inch was needed.
However, PSD's resolution is always measured in pixels per inch, so a
conversion is never necessary.
Removing the conversion, resolves the issue.
created by Adobe Lightroom 5.1
Adobe products are known to write incorrect RichTIFFIPTC tags in TIFF
images.
Since libtiff correctly detects and handles this there is no real need
for end users to be warned. So instead of a warning we will only output
a message to stderr.
This is essentially the same check as done in gimp_image_set_resolution,
but doing it here means we can load the image instead of throwing an
error.
We still need to get replacement xres and yres values, because these are
used to compute layer_offset_x_pixel and layer_offset_y_pixel.
Jehan