Override GimpItem::resize(), instead of GimpLayer::resize(), when
resizing a group layer, so that GimpLayer doesn't try to resize the
mask. Instead, the let the usual mask resizing logic in
GimpGroupLayer handle that.
Also, make sure that the mask is properly restored upon undo when
group resizing is suspended outside of any mask-suspension block,
which can happen when resizing the group.
Add layer-mask support for group layers. Group-layer masks work
similarly to ordinary-layer masks, with the following
considerations:
The group's mask size is the same as group's size (i.e., the
bounding box of its children) at all times. When the group's size
changes, the mask is cropped to the new size -- areas of the mask
that fall outside of the new bounds are discarded and their data is
lost (sans undo), and newly added areas are filled with black (and
hence are transparent by default).
The new gimp_group_layer_{suspend,resume}_mask() functions can be
used to modify this behavior. Between the outermost pair of
suspend/resume calls, the old mask data is remembered, and is used
to fill the newly added areas while cropping the mask when the
group is resized. We override GimpItem::{start,end}_move() for
GimpLayer, to call these functions (suspend() in start_move(), and
resume() in end_move()) for each of the layer's ancestors.
As a result, while moving a layer, or a set of layers, atomically,
such as while dragging with the move tool, or moving linked layers,
the ancestors' mask data is not lost, and is only discarded at the
end of the operation.
This commit also takes care of properly handling undo for group-
layer mask crops, properly invalidating the image when the group
layer's mask is shown, and enabling the mask actions for group
layers (obviously :).
Add gimp_item_{start,end}_move(), and corresponding
GimpItem::{start,end}_move() virtual functions, which should be
called before/after "moving" the item (i.e., translating, scaling,
resizing, flipping, rotating, or transforming the item). Moves
performed between the outermost pair of start/end calls are treated
atomically.
What exactly does "treated atomically" entail depends on the
subclasses -- GimpItem doesn't provide a default implementation for
these functions, so the current commit doesn't change any behavior.
The next commit, which adds layer-mask support for group layers,
uses the functions to avoid cropping the mask too early while a
child is moving.
GimpItem calls {start,end}_move() in the various "move" functions
(gimp_item_{translate,scale,...}(), before performing the actual
operation. Additionally we call the functions in the
gimp_image_item_list_foo() functions, for each participating item,
so that the items are moved as a unit. We call the functions in
the various gimp_image_remove_foo() functions, since removing an
item may affect the size of its ancestors, and is therefore akin to
moving. We also call the functions in GimpEditSelectionTool, so
that the move tool moves items atomically while dragging.
It seems the current code simply forgot to break on indexed types and
therefore hit some g_return_*if_reached() code breaking the logics.
Looking further, I see some code taking care of indexed images and
converting them to RGB. And testing after adding breaks looks like it
works just fine.
So I am assuming this was just forgotten breaks indeed, and not on
purpose not allowing indexed images (if that were the intent though,
this is not how it should be done).
This avoids warnings when the handle positions the handle-transform
tool result in a matrix that transforms the TransformGrid's handles
(which are all invisible) to coordinates that are outside of the
corresponding properties' range.
The result of applying a perspective-transform to a Bezier curve is
only an approximation. When the curve is highly nonlinear, the
result may diverge significantly from the real transformed curve.
Subdivide the curve as necessary in gimp_transform_bezier_coords()
to counter that. Adjust gimp_bezier_stroke_transform()
accordingly.
Normally, the model would try to avoid notifications when a set()
doesn't change anything, but with g_object_set() that's not possible.
Do the same in the propwidgets' callbacks and avoid potentially
expensive notifications at the cost of a cheap g_object_get().
Also fix the syntax of "Since:" and "Deprecated:" annotations.
I was directed by Massimo to some bug which was repeatedly generating
dozens of thousands of GEGL WARNINGs and that was completely taking over
the GUI if redirected to GimpErrorDialog. Currently GEGL warnings are
not redirected there, but the problem is still there, and we don't want
GIMP warnings to freeze the whole GUI either.
So only increment the repeat variable upon gimp_message_box_repeat() and
delay actual GUI update to a later low-priority idle function.
Override GimpStroke::transform() for GimpBezierStroke, using
gimp_transform_bezier_coords() to transform the stroke's segments,
so that clipping done properly.
The next commit is going to perform clipping when transforming
Bezier strokes. When parts of the stroke get clipped, the result
consists of multiple strokes.
Adapt gimp_stroke_transform() in preparation, to allow for the
transformation to result in multiple strokes, by adding a GQueue*
parameter that receives the transformed strokes.
For convenience, we allow passing NULL as the argument, in which
case the current behavior is maintained. However, NULL should only
be passed when clipping is known to be unnecessary.
Adapt the rest of the code for the change.
Note that this technically affects public API: existing stroke
object IDs now become invalid after transforming their containing
vectors object. However, this is unlikely to affect code in
practice.
... which transforms a single cubic Bezier segment, performing
clipping by the near plane, to avoid erroneously transforming parts
of the curve behind the camera.
... which is the same as gimp_transform_polygon(), but using
GimpCoords for the vertices, instead of GimpVector2.
Specify when the input and output arguments may alias, in the
description of gimp_transform_polygon().
Fix indentation, typos, style. Use array parameters for the
control points, instead of using individual by-value parameters.
Use GArray* for the results, instead of GArray**. Verify
arguments.
Adapt the rest of the code to the changes.
The first validation command was actually failing but the test was not,
because only the last return value is taken into account, obviously. Add
a '&&' between the commands.
Also test against the built files, not the templates (in particular
because `appstream-util` doesn't like .in.in templates, and anyway it's
always better to test against the finale file).
Finally move to "validate-relax" test for the time being.
"validate-strict" actually makes a bunch of errors, but I can't make the
time to look at these now. Let's just settle with basic validation at
least.
- appstream-util returns a "style-invalid" error: "<ul> cannot start a
description [(null)]". So I add a <p> introduction to the 2.9.8
<release> tag. This was part of unit test failure on the appdata file.
- I also add a type property for 2.9.8. This is a new property which I
proposed and which just got accepted in the appstream specification:
https://github.com/ximion/appstream/pull/158
- I add <release> tags for all previous 2.9.x releases. No description
for these, just a type property. But feel free to propose patches
adding short non-technical description for these.
Note: it was originally proposed in the bug report to use the appdata
file in place of NEWS (and have this one generated from appdata). But
after discussion with appstream project, appdata is expected to be
concise, non-technical and more "marketing" than exhaustive. This is
quite a different usage than NEWS which is more an exhaustive summary of
new features and major changes. So these 2 files will likely remain
distinct.
filters-commands.c always needs an image and a drawable, so use
return_if_no_drawable(), not return_if_no_display().
Also fix the sensitivity of the shadows-highlights actions, which made
this bug triggerable at all.
When the resulting matrix transforms all input points behind the
camera, negate the matrix, instead of failing, which results in a
matrix that transforms the input points to the corresponding points
in front of the camera. This avoids rejecting certain valid
transforms as invalid, in the generic transform tools (unified,
perspective, and handle transform).
Make the number of input and output points explicit in the
function's signature, and add comments.
I actually think the buttons were translatable, but the strings were
simply not auto-extracted with previous code (which is nearly the same
in the end). Should be better now.
The reason is that this file is now included for a binary in tools/ as
well (the debug binary) and tools/ contents needs to be built before
app/. Even using BUILT_SOURCES in the Makefile under app/ is not enough.
Anyway it makes sense that this file should be under the root of the
repository since that describes the status of the source repository. So
let's move it up one folder.
Please everyone, review the contents of this <release> tag so that we
can quickly uncomment it and submit it for translation. This is what
will be featured in software installers. Let's make it a concise yet
interesting overview of the 2.10 release.
It is nice because when available (Linux only?), it is a lot faster than
using a dedicated debugger such as GDB or LLDB, and also it allows to
always have a backtrace, even when no debuggers are installed.
Unfortunately the output is a lot less detailed, with no file paths, no
line numbers (even when debug symbols are there), no local values
printout, etc. It's pretty bare, with function names and the stack
levels. This is why it is not given priority, and GDB and LLDB are still
preferred when available.
Since commit 9fdf35550b, I removed the GIMP_APP_GLUE_COMPILATION check
because we need to have the whole versioning info from the new debug
widget. It just makes sense to go further and just make this a proper
internal API to get version information.
Ell