If we want to encourage meson usage in GIMP 2.99.12 as a test run, our
INSTALL file should target meson commands and options.
Also I took the opportunity fix a bit some parts which were outdated.
If we want to encourage packagers to test the meson tarball (better to
do this now with development releases than later on stable releases!),
we should name it prominently. Therefore I will rename the autotools
tarball as gimp-*-autotools.tar.bz2 whereas the meson tarball will be
named gimp-*.tar.xz.
Also renaming `sources` CI job to `sources-autotools`.
When zooming using scroll events it is possible to zoom out of gradient
bounds because the check for out of bounds zoom happens with the zoom
value before the delta is applied. The correct way is to limit the zoom
value after the delta is applied.
Zoom focus centers the point that we're zooming into at the location of
the mouse pointer.
Default zoom focus value is 0.5 which results in previous behavior.
Smooth scrolling requires that we keep the scroll (or zoom, as is in
this case) state as a floating-point number. The scroll deltas are often
less than one, thus storing scroll state as an integer will effectively
ignore most of the scroll events.
Apparently some layers in PSD files can have extra channels which we
did not account for when computing destination offsets, causing crashes.
So let's make sure we don't include the "extra" channels when computing
the offsets by introducing base_channels. We also move the alpha channel
in the spot of the first extra channel (even though it seems, based on
the one example we have, that the extra channel might be the same as
the alpha channel).
Commit a6aba929 deleted the old functions.
Misc drive-by fixes for gtk_adjustment step not < pages
Issue #8155 discusses alternative fixes, convenience functions for compatibility in ScriptFu.
There is one compat function defined already in ScriptFu, temporarily: gimp-image-get-active-drawable
which was written so that testing clothify-v3.scm could proceed.
* gimp-zip.in was apparently a very old script to package GIMP for
Windows into zip files. It has not been updated since 2007 and these
days, we package GIMP as an installer for Windows. I guess the need of
having just a compressed folder to move might be wanted for some, but
anyway this script is so old, it's probably completely broken now. It
would be much simpler to redo such a process from scratch (we have
very close jobs in the CI which could be better bases to work from).
* config.h.win32 seems to be an old manually-maintained config.h and it
has a big "WARNING! OUTDATED!" text at the top (also untouched since
2007). I guess it might have been used some time long ago. But these
days, we don't need a specific Windows-only config.h. The generated
one works fine.
`meson dist` don't imply a reconfigure or a rebuild which is actually
not great as it means a wrong order of commands may create tarballs with
outdated data (typically: build, then pull new code, then dist).
Of course for our official tarballs, it should be fine as we don't
generate tarballs manually anymore, but through the CI. Yet, just to be
on the safe side, force-trigger a reconfigure then a build (which would
likely be very fast anyway in the common use case where we just did a
build right before).
Additionally the INSTALL.in file is not copied anymore in the tarball
and INSTALL will only be generated in git repositories.
Resolves#8382
Also v2 scripts infer and set sensitivity to drawables
Add two test plugins clothify-v3.scm and test-sphere-v3.scm.
Temporary, to be removed when 3.0 ships.
Some refactoring (extracting methods, moving functions to new files).
Some drive-by fixes to script-fu-arg.c revealed by using GimpProcedureDialog.
Adds a soft-proof toggle button to GimpStatusBar. It's only active when
a simulation profile is set on the current image. It stays in sync with
the View menu soft-proofing option as well.
The `ninja dist` step fails with:
> ERROR: Repository has uncommitted changes that will not be included in the dist tarball
> Use --allow-dirty to ignore the warning and proceed anyway
> FAILED: meson-dist
> /usr/bin/meson dist
Astonishingly if I run a `git diff` (or git status) in the CI, I saw no
changes and the dist suddenly succeeded. When I remove it, it fails
again. And of course, locally it's alright. No way to diagnose!
Anyway it's not a bad idea to leave some diagnostic logs in the CI so
here we go, properly outputting the diff and exiting the job with an
error when there is a diff. Because anyway, there should be none. It
would mean that there is likely some issue in versionned generated
files.
Ironically, it is a test for the Windows platform but it cannot run on
Windows. First, because it expects a .so (which could be easily fixed),
but even more because from web search, it looks like the nm tool may not
exist on Windows (though I haven't checked).
Anyway we only ever ran it from Linux machines and up to now, it worked
just fine and was useful anyway. So let's go with it.
Also clean a bit remnants from older attempts to run this script.
Maybe let's try to distribute the meson tarball next to the autotools
tarball for our next dev release, and announce that packagers are
invited to test the meson build from tarball and report back.
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.
The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
Displaying it all the time when we fail the first attempt is confusing
as it is expected to fail in the meson build (since build libraries are
in different folders). Instead only output the error message when both
known paths failed, i.e. when we fail the script (and write down both
attempted path in the error message).
This explains why the defcheck script never complained for the 2
*_get_resource() functions removed in my previous commit. These were
exported in the libgimpwidgets library on the autotools build (and not
on the meson build).
Fix the discrepancy by not exporting these symbols on autotools as well,
as I don't think this is needed on public API.
This should now fix the distcheck build for autotools.
The defcheck.py file finds these errors:
> Problem found in /home/jehan/dev/src/gimp/libgimpwidgets/gimpwidgets.def
> the following symbols are listed in the .def-file,
> but are not exported by the library.
> - gimp_color_picker_cursors_get_resource
> - gimp_icon_pixbufs_get_resource
Indeed these don't exist. Unsure why the autootols check failed to
report these until today.
The check script now takes into account both the autotools and meson
file hierarchy (in autotools, built libs are in .libs/ subdirs).
Also it now properly fails on missing lib.
Adds a parasite to .xcf that stores the soft-proofing profile.
Existing color profile saving/loading functions now take in a
parasite name parameter so they can be used for either profile.
Yuri Chornoivan