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.
This does not mean that our patterns are all of a sudden "proper" now,
but the categories (except "Legacy") hopefully make sense for new high
quality patterns that will be added, and it's better than having them
all untagged.
This patch adds a Dynamic for the 'Color From Gradient' option
and three Paint tool presets (Airbrush, Paintbrush, Pencil), which
use this preset.
new file: data/dynamics/Color-From-Gradient.gdyn
new file: data/tool-presets/Paint/Airbrush-Color-From-Gradient.gtp
new file: data/tool-presets/Paint/Paintbrush-Color-From-Gradient.gtp
new file: data/tool-presets/Paint/Pencil-Color-From-Gradient.gtp
modified: data/dynamics/Makefile.am
modified: data/tool-presets/Paint/Makefile.am
modified: AUTHORS
modified: authors.xml
(cherry picked from commit 54b28a5b60)
Aryeom Han