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.
(cherry picked from commit 845f1c81ed)
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!
(cherry picked from commit f9cc239f2c)
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.
(cherry picked from commit cd924f453a)
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.
