- 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).
(1) On recent meson versions, it fixes this error:
> extensions/goat-exercises/meson.build:108:0: ERROR: i18n.merge_file keyword argument 'output' was of type array[str] but should have been str
As docs explains, 'output' only accepts one item in i18n.merge_file().
This bug also happens on older meson (but there the reported error is a
lot less useful as it doesn't mention local meson build code).
(2) `setup.isl.xml` is a temporary intermediary file used to create the
Windows installer. It must not be installed.
(3) `gimp30-windows-installer.mo` itself is only used to create
`setup.isl.xml`. It must not be installed as well.
(4) gimp-tips.(its|loc) files (same for gimp-tags ones) should not be
installed. They are only temporary data.
(5) Fix environment variable: s/GETTEXT_DATA_DIRS/GETTEXTDATADIRS/
Fixes:
> /usr/bin/msgfmt: cannot locate ITS rules for ../../../data/tips/gimp-tips.xml.in
(6) Fix various bugs in the *.setup.isl files creation in autotools
build (typo, wrong files used, order of options in `xsltproc`
apparently meaningful, and so on. I guess the autotools build was
not as well tested as the meson one :P).
(7) Fixing the unit test verifying language lists consistency.
(8) `setup.isl.xml.in` must be added to the distribution.
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
The '\n' newline is transformed into a space (0x20) when building
natively on Windows. And unfortunately g_key_file_load_from_file() does
not like this.
The autotools rule works properly on all platforms according to my
tests.
Note that at first, I thought it was a LF vs. CRLF issue, and tried to
special-case Windows, but I realized it's just that 'echo' command
seemingly transform newlines unexpectedly in its Windows form. I didn't
want to waste too much time experimenting alternative calls, especially
as I have to test through CI (so each test is very costly, time-wise).
Instead I go the alternative way of using a pre-generated conf file.
Fixes#4333
If the checkbox is unchecked: dynamics falls back to "Dynamics Off",
the current dynamics name and its options are hidden in the UI.
If the checkbox is checked: dynamics is set to previously used one
or the default one, all dynamics options are seen in the UI.
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
Similarly to the previous commit, the tips and tags validation was never
happening as it was implemented as a custom top-level meson target. It
was not run during a normal build. Now it is.
We have a sudden CI failure which is maybe because of a change of
intltool-merge. We believe it might be because of a missing directory.
Let's test making it before running the command.
Fixes:
> /usr/bin/intltool-merge ../../../po-tags
> ../../../data/tags/gimp-tags-default.xml.in gimp-tags-default.xml -x -u
> -c ../../po-tags/.intltool-merge-cache
> No such file or directory at /usr/bin/intltool-merge line 396.
Clean up faint pixels in the "Acrylic 05" brush, which produce a
badly-thresholded mask with the Pencil tool. See issue #5180.
Thanks to Sevenix for the fixed brush!
This was my initial choice, but the more I think about it, the less I am
sure this was the right choice. There was some common code (as I was
making a common composite bucket fill once the line art was generated),
but there is also a lot of different code and the functions were filled
of exception when we were doing a line art fill. Also though there is a
bit of color works (the way we decide whether a pixel is part of a
stroke or not, though currently this is basic grayscale threshold), this
is really not the same as other criterions. In particular this was made
obvious on the Select by Color tool where the line art criterion was
completely meaningless and would have had to be opted-out!
This commit split a bit the code. Instead of finding the line art in the
criterion list, I add a third choice to the "Fill whole selection"/"Fill
similar colors" radio. In turn I create a new GimpBucketFillArea type
with the 3 choices, and remove line art value from GimpSelectCriterion.
I am not fully happy yet of this code, as it creates a bit of duplicate
code, and I would appreciate to move some code away from gimpdrawable-*
and gimppickable-* files. This may happen later. I break the work in
pieces to not get too messy.
Also this removes access to the smart colorization from the API, but
that's probably ok as I prefer to not freeze options too early in the
process since API needs to be stable. Probably we should get a concept
of experimental API.
This reverts commit ea3de6d524.
Previous splash had never been used in a dev release. Let's use it for
GIMP 3 port. Updating also the version number to display "2.99".
Green Is My Pepper!
These were mostly kept for scripts which needed to keep working. Since
we don't ensure compatibility anymore, let's just get rid of old
deprecated data.
Extract of a selection by Jose Americo Gobbo.
Reviewed by Aryeom and myself for integration.
From what I could gather, authors are:
- Grunge 01 by Rene Jensen.
- Stone Work 01 by Mathias Jonathan (Griffeur).
- Pencil 03 and Charcoal 03 by Americo.
According to information from Americo, all data is GPL v3.0.
Things are getting serious now. We need a reasonnable splash, right?
Just in case we have a RC3!
It follows all rules: full HD and bottom fourth empty for loading text.
So I discover the concept of obsolete data in GIMP where some data can
be apparently unavailable in the GUI, but still selectable by script.
This somehow reverts commit 26cb87aa2d
then moves the brushes into the obsolete section instead of simple
deletion. This way, any script using the said brushes won't break at
least.
We will definitely remove the brushes for 3.0, but for now it's better
to keep scripts as compatible as possible.
It was reported that several brushes added in 1998 may have problematic
copyright with unclear/unknown licensing. And basically nobody knows
anymore where these actually come from, with which authorship or origin,
at least not for sure. It is even possible some come from commercial
software. So let's at least get rid of the ones where the origin is the
most doubtful.
Thanks to Americo for discovering these issues.
Current phrasing seemed to imply that you could chose another format
than XCF to *save* your work-in-progress image. Reword a bit to make
obvious that "saving" is always done with XCF. Other formats are for
exporting.
This is a common dynamics, for instance when you do colorization bases.
This allows to control the size of the brush with pressure and always
keep unified color without opacity changes.
Rather than just discovering them by chance, a simple grep and some
search and replace are much more efficient! :-)
Cleaning only done on C and automake files.
Jehan