In other words, number the release candidates: 2.10.0~rc*.
In any case, this makes `rpmdev-vercmp` to consider them before 2.10.0,
unlike using a hyphen separator.
Though I still leave the <releases> trick from commit fb6328b9ad so that
our unit test succeeds, since `appstream-util` still considers the other
order.
gimp_rectangle_select_tool_cursor_update(): always set a cursor and
cursor modifier even if no GimpToolRectangle widget exists, so we are
not stuck with the last set cursor after committing or halting the
tool.
Symmetric conical gradients only span half a revolution (unlike
assymetric ones, which span an entire revolution), and therefore
require only half the cache size.
Add a crop node to the GimpDrawableFilter graph, applied after the
filter's output, cropping the output to the filter area (the same
area used for the input crop node). If we fail to do this, filters
whose op's bounding box is bigger than the input region can affect
areas outside the drawable, when the filter is rendered as part of
the image graph (in contrast to being comitted). This is
particularly relevant to source ops, that may have an infinite
bounding box.
We probably didn't notice this until now, since before the recent
GimpProjection update-area changes, only the drawable's area would
get invalidated in response to changes in the filter, so regions
outside the drawable wouldn't normally get rendered. However, this
could still have been triggered by causing regions outside the
drawable to be invalidated by other means.
Adding today's (hopeful) date.
Also removing the trick from commit 447d9bbc56 because the bug in
appstream-util has been fixed, but adding the same trick elsewhere for
another bug in this validation script:
https://github.com/hughsie/appstream-glib/issues/234
Add gimp_drawable_gradient_adjust_coords(), which adjusts the
gradient segment coords according to the gradient type, so that, in
cases where the gradient span is unrelated to the segment length,
the gradient cache (in GimpOperationGradient) is big enough not to
produce banding. Use the new function in gimp_drawable_gradient()
and in the gradient tool, instead of duplicating the logic.
Move the shapreburst coordinate-adjustment logic to the new
function, and add appropriate logic for conical gradients.
Remove the code that avoids using the gradient cache for conical
gradients from GimpOperationGradient.
Undo the part of commit fa9a4108c3
that moved cache generation from process() to prepare(). prepare()
is called after each property change, in order to calculate the
op's bounding box for invalidation. Since we only need the cache
for actual processing, generating it in process() avoids that
overhead.
In the various types of fill operations, and in fade operations,
use the paint composite-mode of the current paint mode, which is
the composite mode we use during painting, instead of AUTO, which
results in the default mode we use for layer compositing. This
effectively means that filling using any non-legacy, non-
subtractive mode can paint over transparent areas, rather than
being limited to nontransparent areas.
Invalidate the gradient cache while setting relevant properties,
and validate it, reconstructing if necessary, during prepare(),
rather than process(), to avoid the need to use a mutex.
Make sure the cache has at least two elements, corresponding to
the initial and final colors of the gradient, since both colors
might be needed, and to avoid division by zero.
Avoid using a cache if its necessary size is too big, or if the
gradient type is conical, since the necessary cache size for
conical gradients is unrelated to the gradient line length.
Improve index rounding during cache lookup.
Lots of indentation fixes.
When merging a pass-through group, change its mode to NORMAL first,
to avoid a critical when duplicating the group as a regular layer.
Preserve the group's blend/composite space/mode while changing its
mode (note that only the composite space currently matters, since
the other parmaeters are immutable for pass-through groups.)
I could not find for sure what to use on FreeBSD instead, so let's just
not get this information there. It is quite useful information to know
where thread traces were asked from, but it is more important to make
sure the program can be compiled everywhere. Also we can just check
which thread has gimp_stack_trace*() calls. Thus it can be seen as
redundant information in any case.
SYS_gettid is apparently defined as a macro, so let's simply check for
it being defined.
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.
In gimp_text_tool_connect(), when auto-removing empty text layers upon
text layer or tool change, make sure we don't try to remove a layer
that has already been removed, which can happen if this function is
reached *because* somehow the layer was removed externally (e.g. by
the user in the layers dialog).
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.
Michael Natterer