2006-12-10 05:33:38 +08:00
|
|
|
/* GIMP - The GNU Image Manipulation Program
|
2006-05-21 19:32:41 +08:00
|
|
|
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
|
|
|
|
*
|
2009-01-18 06:28:01 +08:00
|
|
|
* This program is free software: you can redistribute it and/or modify
|
2006-05-21 19:32:41 +08:00
|
|
|
* it under the terms of the GNU General Public License as published by
|
2009-01-18 06:28:01 +08:00
|
|
|
* the Free Software Foundation; either version 3 of the License, or
|
2006-05-21 19:32:41 +08:00
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2009-01-18 06:28:01 +08:00
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
2006-05-21 19:32:41 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
2013-10-15 07:58:39 +08:00
|
|
|
#include <gdk-pixbuf/gdk-pixbuf.h>
|
2008-10-10 04:24:04 +08:00
|
|
|
#include <gegl.h>
|
2006-05-21 19:32:41 +08:00
|
|
|
|
2015-07-02 09:28:53 +08:00
|
|
|
#include "libgimpbase/gimpbase.h"
|
|
|
|
|
2006-05-21 19:32:41 +08:00
|
|
|
#include "core-types.h"
|
|
|
|
|
|
|
|
#include "gimpcontext.h"
|
|
|
|
#include "gimpimage.h"
|
|
|
|
#include "gimpimage-item-list.h"
|
|
|
|
#include "gimpimage-undo.h"
|
|
|
|
#include "gimpitem.h"
|
app: use GimpObjectQueue in lots of places
Use GimpObjectQueue, added in the previous commit, in various
instances where we perform an action on a set of objects. This
improves progress reporting, by using a single progress for the
entire operation, rather than reporting the progress of each object
individually, and by taking the relative cost of each object into
account, instead of assuming a uniform cost for all objects.
In particular, this affects the various whole-image operations
(i.e., transformations and color conversions), operations on linked
items, and operations on layer groups. This also affects layers
with masks, whose progress is now reported together instead of
individually.
Additionally, this commit fixes erroneous group-layer mask cropping
during undo when resizing the image, by properly calling
{start,end}_move() on all the resized layers before starting the
operation, and when scaling the image, by only scaling top-level
layers, and letting group layers scale their children themselves.
2018-03-25 22:18:46 +08:00
|
|
|
#include "gimpobjectqueue.h"
|
2006-05-21 19:32:41 +08:00
|
|
|
#include "gimpprogress.h"
|
|
|
|
|
|
|
|
#include "gimp-intl.h"
|
|
|
|
|
|
|
|
|
|
|
|
/* public functions */
|
|
|
|
|
2015-07-02 09:28:53 +08:00
|
|
|
gboolean
|
|
|
|
gimp_image_item_list_bounds (GimpImage *image,
|
|
|
|
GList *list,
|
|
|
|
gint *x,
|
|
|
|
gint *y,
|
|
|
|
gint *width,
|
|
|
|
gint *height)
|
|
|
|
{
|
|
|
|
GList *l;
|
|
|
|
gboolean bounds = FALSE;
|
|
|
|
|
|
|
|
g_return_val_if_fail (GIMP_IS_IMAGE (image), FALSE);
|
|
|
|
g_return_val_if_fail (x != 0, FALSE);
|
|
|
|
g_return_val_if_fail (y != 0, FALSE);
|
|
|
|
g_return_val_if_fail (width != 0, FALSE);
|
|
|
|
g_return_val_if_fail (height != 0, FALSE);
|
|
|
|
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
|
|
|
{
|
|
|
|
GimpItem *item = l->data;
|
|
|
|
gint tmp_x, tmp_y;
|
|
|
|
gint tmp_w, tmp_h;
|
|
|
|
|
|
|
|
if (gimp_item_bounds (item, &tmp_x, &tmp_y, &tmp_w, &tmp_h))
|
|
|
|
{
|
|
|
|
gint off_x, off_y;
|
|
|
|
|
|
|
|
gimp_item_get_offset (item, &off_x, &off_y);
|
|
|
|
|
|
|
|
if (bounds)
|
|
|
|
{
|
|
|
|
gimp_rectangle_union (*x, *y, *width, *height,
|
|
|
|
tmp_x + off_x, tmp_y + off_y,
|
|
|
|
tmp_w, tmp_h,
|
|
|
|
x, y, width, height);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
*x = tmp_x + off_x;
|
|
|
|
*y = tmp_y + off_y;
|
|
|
|
*width = tmp_w;
|
|
|
|
*height = tmp_h;
|
|
|
|
|
|
|
|
bounds = TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (! bounds)
|
|
|
|
{
|
|
|
|
*x = 0;
|
|
|
|
*y = 0;
|
|
|
|
*width = gimp_image_get_width (image);
|
|
|
|
*height = gimp_image_get_height (image);
|
|
|
|
}
|
|
|
|
|
|
|
|
return bounds;
|
|
|
|
}
|
|
|
|
|
2006-05-21 19:32:41 +08:00
|
|
|
void
|
|
|
|
gimp_image_item_list_translate (GimpImage *image,
|
|
|
|
GList *list,
|
|
|
|
gint offset_x,
|
|
|
|
gint offset_y,
|
|
|
|
gboolean push_undo)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_IS_IMAGE (image));
|
|
|
|
|
|
|
|
if (list)
|
|
|
|
{
|
|
|
|
GList *l;
|
|
|
|
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
if (list->next)
|
|
|
|
{
|
|
|
|
if (push_undo)
|
|
|
|
{
|
|
|
|
gimp_image_undo_group_start (image, GIMP_UNDO_GROUP_ITEM_DISPLACE,
|
|
|
|
C_("undo-type", "Translate Items"));
|
|
|
|
}
|
|
|
|
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
Bug 795410 - Deleting a layer group and then undoing the deletion ...
... raises a CRITICAL
gimp_item_{start,end}_move() currently serves two different
purposes: It is used by GimpLayer to suspend/resume mask resizing
of the layer's ancestors; this is necessary whenever an operation
on a layer might affect the size of its ancestors. It is also used
by GimpGroupLayer to suspend/resume its own mask resizing; this, on
the other hand, is only necessary before applying one of the
transformation functions to the group, so that mask modification is
handled by GimpLayer. In other words, the effects of
gimp_item_{start,end}_move() on group layers are only necessary in
a subset of the cases in which these functions are used.
While in itself this isn't a problem, it does cause issues when
removing a group layer: gimp_image_remove_layer() calls
gimp_item_start_move() before removing the layer, and
gimp_item_end_move() afterwards. While the former function is
called while the layer is still attached to the image, the latter
function is called after the layer is no longer attached. Since
GimpGroupLayer pushes an undo step in response to these calls, only
the call to start_move() results in an undo step, while the call to
end_move() doesn't, resulting in an unbalanced
GIMP_UNDO_GROUP_LAYER_START_MOVE undo step on the stack. This
causes problems when undoing the operation.
Add gimp_item_{start,end}_transform() functions, and corresponding
GimpItem::{start,end}_transform() virtual functions, which are more
specialized versions of gimp_item_{start,end}_move(), which should
be used instead of the former before/after transforming an item; in
other cases, such as when removing ot reordering an item,
gimp_item_{start,end}_move() should still be used. The default
implementation of GimpItem::{start,end}_transform() calls
gimp_item_{start,end}_move(), respectively, so subclasses that
override these functions don't have to do that themselves.
In GimpGroupLayer, override GimpItem::{start,end}_transform(),
instead of GimpItem::{start,end}_move(), for the same purpose of
suspending mask resize. This avoids these functions from being
called when removing a layer group, fixing the bug.
2018-04-22 15:39:40 +08:00
|
|
|
gimp_item_start_transform (GIMP_ITEM (l->data), push_undo);
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
}
|
2006-05-21 19:32:41 +08:00
|
|
|
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
|
|
|
gimp_item_translate (GIMP_ITEM (l->data),
|
|
|
|
offset_x, offset_y, push_undo);
|
|
|
|
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
if (list->next)
|
|
|
|
{
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
Bug 795410 - Deleting a layer group and then undoing the deletion ...
... raises a CRITICAL
gimp_item_{start,end}_move() currently serves two different
purposes: It is used by GimpLayer to suspend/resume mask resizing
of the layer's ancestors; this is necessary whenever an operation
on a layer might affect the size of its ancestors. It is also used
by GimpGroupLayer to suspend/resume its own mask resizing; this, on
the other hand, is only necessary before applying one of the
transformation functions to the group, so that mask modification is
handled by GimpLayer. In other words, the effects of
gimp_item_{start,end}_move() on group layers are only necessary in
a subset of the cases in which these functions are used.
While in itself this isn't a problem, it does cause issues when
removing a group layer: gimp_image_remove_layer() calls
gimp_item_start_move() before removing the layer, and
gimp_item_end_move() afterwards. While the former function is
called while the layer is still attached to the image, the latter
function is called after the layer is no longer attached. Since
GimpGroupLayer pushes an undo step in response to these calls, only
the call to start_move() results in an undo step, while the call to
end_move() doesn't, resulting in an unbalanced
GIMP_UNDO_GROUP_LAYER_START_MOVE undo step on the stack. This
causes problems when undoing the operation.
Add gimp_item_{start,end}_transform() functions, and corresponding
GimpItem::{start,end}_transform() virtual functions, which are more
specialized versions of gimp_item_{start,end}_move(), which should
be used instead of the former before/after transforming an item; in
other cases, such as when removing ot reordering an item,
gimp_item_{start,end}_move() should still be used. The default
implementation of GimpItem::{start,end}_transform() calls
gimp_item_{start,end}_move(), respectively, so subclasses that
override these functions don't have to do that themselves.
In GimpGroupLayer, override GimpItem::{start,end}_transform(),
instead of GimpItem::{start,end}_move(), for the same purpose of
suspending mask resize. This avoids these functions from being
called when removing a layer group, fixing the bug.
2018-04-22 15:39:40 +08:00
|
|
|
gimp_item_end_transform (GIMP_ITEM (l->data), push_undo);
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
|
|
|
|
if (push_undo)
|
|
|
|
gimp_image_undo_group_end (image);
|
|
|
|
}
|
2006-05-21 19:32:41 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gimp_image_item_list_flip (GimpImage *image,
|
|
|
|
GList *list,
|
|
|
|
GimpContext *context,
|
|
|
|
GimpOrientationType flip_type,
|
|
|
|
gdouble axis,
|
|
|
|
gboolean clip_result)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_IS_IMAGE (image));
|
|
|
|
g_return_if_fail (GIMP_IS_CONTEXT (context));
|
|
|
|
|
|
|
|
if (list)
|
|
|
|
{
|
|
|
|
GList *l;
|
|
|
|
|
2015-06-26 19:35:07 +08:00
|
|
|
if (list->next)
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
{
|
|
|
|
gimp_image_undo_group_start (image, GIMP_UNDO_GROUP_TRANSFORM,
|
|
|
|
C_("undo-type", "Flip Items"));
|
|
|
|
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
Bug 795410 - Deleting a layer group and then undoing the deletion ...
... raises a CRITICAL
gimp_item_{start,end}_move() currently serves two different
purposes: It is used by GimpLayer to suspend/resume mask resizing
of the layer's ancestors; this is necessary whenever an operation
on a layer might affect the size of its ancestors. It is also used
by GimpGroupLayer to suspend/resume its own mask resizing; this, on
the other hand, is only necessary before applying one of the
transformation functions to the group, so that mask modification is
handled by GimpLayer. In other words, the effects of
gimp_item_{start,end}_move() on group layers are only necessary in
a subset of the cases in which these functions are used.
While in itself this isn't a problem, it does cause issues when
removing a group layer: gimp_image_remove_layer() calls
gimp_item_start_move() before removing the layer, and
gimp_item_end_move() afterwards. While the former function is
called while the layer is still attached to the image, the latter
function is called after the layer is no longer attached. Since
GimpGroupLayer pushes an undo step in response to these calls, only
the call to start_move() results in an undo step, while the call to
end_move() doesn't, resulting in an unbalanced
GIMP_UNDO_GROUP_LAYER_START_MOVE undo step on the stack. This
causes problems when undoing the operation.
Add gimp_item_{start,end}_transform() functions, and corresponding
GimpItem::{start,end}_transform() virtual functions, which are more
specialized versions of gimp_item_{start,end}_move(), which should
be used instead of the former before/after transforming an item; in
other cases, such as when removing ot reordering an item,
gimp_item_{start,end}_move() should still be used. The default
implementation of GimpItem::{start,end}_transform() calls
gimp_item_{start,end}_move(), respectively, so subclasses that
override these functions don't have to do that themselves.
In GimpGroupLayer, override GimpItem::{start,end}_transform(),
instead of GimpItem::{start,end}_move(), for the same purpose of
suspending mask resize. This avoids these functions from being
called when removing a layer group, fixing the bug.
2018-04-22 15:39:40 +08:00
|
|
|
gimp_item_start_transform (GIMP_ITEM (l->data), TRUE);
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
}
|
2006-05-21 19:32:41 +08:00
|
|
|
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
|
|
|
gimp_item_flip (GIMP_ITEM (l->data), context,
|
|
|
|
flip_type, axis, clip_result);
|
|
|
|
|
2015-06-26 19:35:07 +08:00
|
|
|
if (list->next)
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
{
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
Bug 795410 - Deleting a layer group and then undoing the deletion ...
... raises a CRITICAL
gimp_item_{start,end}_move() currently serves two different
purposes: It is used by GimpLayer to suspend/resume mask resizing
of the layer's ancestors; this is necessary whenever an operation
on a layer might affect the size of its ancestors. It is also used
by GimpGroupLayer to suspend/resume its own mask resizing; this, on
the other hand, is only necessary before applying one of the
transformation functions to the group, so that mask modification is
handled by GimpLayer. In other words, the effects of
gimp_item_{start,end}_move() on group layers are only necessary in
a subset of the cases in which these functions are used.
While in itself this isn't a problem, it does cause issues when
removing a group layer: gimp_image_remove_layer() calls
gimp_item_start_move() before removing the layer, and
gimp_item_end_move() afterwards. While the former function is
called while the layer is still attached to the image, the latter
function is called after the layer is no longer attached. Since
GimpGroupLayer pushes an undo step in response to these calls, only
the call to start_move() results in an undo step, while the call to
end_move() doesn't, resulting in an unbalanced
GIMP_UNDO_GROUP_LAYER_START_MOVE undo step on the stack. This
causes problems when undoing the operation.
Add gimp_item_{start,end}_transform() functions, and corresponding
GimpItem::{start,end}_transform() virtual functions, which are more
specialized versions of gimp_item_{start,end}_move(), which should
be used instead of the former before/after transforming an item; in
other cases, such as when removing ot reordering an item,
gimp_item_{start,end}_move() should still be used. The default
implementation of GimpItem::{start,end}_transform() calls
gimp_item_{start,end}_move(), respectively, so subclasses that
override these functions don't have to do that themselves.
In GimpGroupLayer, override GimpItem::{start,end}_transform(),
instead of GimpItem::{start,end}_move(), for the same purpose of
suspending mask resize. This avoids these functions from being
called when removing a layer group, fixing the bug.
2018-04-22 15:39:40 +08:00
|
|
|
gimp_item_end_transform (GIMP_ITEM (l->data), TRUE);
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
|
|
|
|
gimp_image_undo_group_end (image);
|
|
|
|
}
|
2006-05-21 19:32:41 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gimp_image_item_list_rotate (GimpImage *image,
|
|
|
|
GList *list,
|
|
|
|
GimpContext *context,
|
|
|
|
GimpRotationType rotate_type,
|
|
|
|
gdouble center_x,
|
|
|
|
gdouble center_y,
|
|
|
|
gboolean clip_result)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_IS_IMAGE (image));
|
|
|
|
g_return_if_fail (GIMP_IS_CONTEXT (context));
|
|
|
|
|
|
|
|
if (list)
|
|
|
|
{
|
|
|
|
GList *l;
|
|
|
|
|
2015-06-26 19:35:07 +08:00
|
|
|
if (list->next)
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
{
|
|
|
|
gimp_image_undo_group_start (image, GIMP_UNDO_GROUP_TRANSFORM,
|
|
|
|
C_("undo-type", "Rotate Items"));
|
|
|
|
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
Bug 795410 - Deleting a layer group and then undoing the deletion ...
... raises a CRITICAL
gimp_item_{start,end}_move() currently serves two different
purposes: It is used by GimpLayer to suspend/resume mask resizing
of the layer's ancestors; this is necessary whenever an operation
on a layer might affect the size of its ancestors. It is also used
by GimpGroupLayer to suspend/resume its own mask resizing; this, on
the other hand, is only necessary before applying one of the
transformation functions to the group, so that mask modification is
handled by GimpLayer. In other words, the effects of
gimp_item_{start,end}_move() on group layers are only necessary in
a subset of the cases in which these functions are used.
While in itself this isn't a problem, it does cause issues when
removing a group layer: gimp_image_remove_layer() calls
gimp_item_start_move() before removing the layer, and
gimp_item_end_move() afterwards. While the former function is
called while the layer is still attached to the image, the latter
function is called after the layer is no longer attached. Since
GimpGroupLayer pushes an undo step in response to these calls, only
the call to start_move() results in an undo step, while the call to
end_move() doesn't, resulting in an unbalanced
GIMP_UNDO_GROUP_LAYER_START_MOVE undo step on the stack. This
causes problems when undoing the operation.
Add gimp_item_{start,end}_transform() functions, and corresponding
GimpItem::{start,end}_transform() virtual functions, which are more
specialized versions of gimp_item_{start,end}_move(), which should
be used instead of the former before/after transforming an item; in
other cases, such as when removing ot reordering an item,
gimp_item_{start,end}_move() should still be used. The default
implementation of GimpItem::{start,end}_transform() calls
gimp_item_{start,end}_move(), respectively, so subclasses that
override these functions don't have to do that themselves.
In GimpGroupLayer, override GimpItem::{start,end}_transform(),
instead of GimpItem::{start,end}_move(), for the same purpose of
suspending mask resize. This avoids these functions from being
called when removing a layer group, fixing the bug.
2018-04-22 15:39:40 +08:00
|
|
|
gimp_item_start_transform (GIMP_ITEM (l->data), TRUE);
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
}
|
2006-05-21 19:32:41 +08:00
|
|
|
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
|
|
|
gimp_item_rotate (GIMP_ITEM (l->data), context,
|
|
|
|
rotate_type, center_x, center_y, clip_result);
|
|
|
|
|
2015-06-26 19:35:07 +08:00
|
|
|
if (list->next)
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
{
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
Bug 795410 - Deleting a layer group and then undoing the deletion ...
... raises a CRITICAL
gimp_item_{start,end}_move() currently serves two different
purposes: It is used by GimpLayer to suspend/resume mask resizing
of the layer's ancestors; this is necessary whenever an operation
on a layer might affect the size of its ancestors. It is also used
by GimpGroupLayer to suspend/resume its own mask resizing; this, on
the other hand, is only necessary before applying one of the
transformation functions to the group, so that mask modification is
handled by GimpLayer. In other words, the effects of
gimp_item_{start,end}_move() on group layers are only necessary in
a subset of the cases in which these functions are used.
While in itself this isn't a problem, it does cause issues when
removing a group layer: gimp_image_remove_layer() calls
gimp_item_start_move() before removing the layer, and
gimp_item_end_move() afterwards. While the former function is
called while the layer is still attached to the image, the latter
function is called after the layer is no longer attached. Since
GimpGroupLayer pushes an undo step in response to these calls, only
the call to start_move() results in an undo step, while the call to
end_move() doesn't, resulting in an unbalanced
GIMP_UNDO_GROUP_LAYER_START_MOVE undo step on the stack. This
causes problems when undoing the operation.
Add gimp_item_{start,end}_transform() functions, and corresponding
GimpItem::{start,end}_transform() virtual functions, which are more
specialized versions of gimp_item_{start,end}_move(), which should
be used instead of the former before/after transforming an item; in
other cases, such as when removing ot reordering an item,
gimp_item_{start,end}_move() should still be used. The default
implementation of GimpItem::{start,end}_transform() calls
gimp_item_{start,end}_move(), respectively, so subclasses that
override these functions don't have to do that themselves.
In GimpGroupLayer, override GimpItem::{start,end}_transform(),
instead of GimpItem::{start,end}_move(), for the same purpose of
suspending mask resize. This avoids these functions from being
called when removing a layer group, fixing the bug.
2018-04-22 15:39:40 +08:00
|
|
|
gimp_item_end_transform (GIMP_ITEM (l->data), TRUE);
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
|
|
|
|
gimp_image_undo_group_end (image);
|
|
|
|
}
|
2006-05-21 19:32:41 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gimp_image_item_list_transform (GimpImage *image,
|
|
|
|
GList *list,
|
|
|
|
GimpContext *context,
|
|
|
|
const GimpMatrix3 *matrix,
|
|
|
|
GimpTransformDirection direction,
|
|
|
|
GimpInterpolationType interpolation_type,
|
2006-12-25 00:48:08 +08:00
|
|
|
GimpTransformResize clip_result,
|
2006-05-21 19:32:41 +08:00
|
|
|
GimpProgress *progress)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_IS_IMAGE (image));
|
|
|
|
g_return_if_fail (GIMP_IS_CONTEXT (context));
|
|
|
|
g_return_if_fail (progress == NULL || GIMP_IS_PROGRESS (progress));
|
|
|
|
|
|
|
|
if (list)
|
|
|
|
{
|
app: use GimpObjectQueue in lots of places
Use GimpObjectQueue, added in the previous commit, in various
instances where we perform an action on a set of objects. This
improves progress reporting, by using a single progress for the
entire operation, rather than reporting the progress of each object
individually, and by taking the relative cost of each object into
account, instead of assuming a uniform cost for all objects.
In particular, this affects the various whole-image operations
(i.e., transformations and color conversions), operations on linked
items, and operations on layer groups. This also affects layers
with masks, whose progress is now reported together instead of
individually.
Additionally, this commit fixes erroneous group-layer mask cropping
during undo when resizing the image, by properly calling
{start,end}_move() on all the resized layers before starting the
operation, and when scaling the image, by only scaling top-level
layers, and letting group layers scale their children themselves.
2018-03-25 22:18:46 +08:00
|
|
|
GimpObjectQueue *queue = NULL;
|
|
|
|
GList *l;
|
|
|
|
|
|
|
|
if (progress)
|
|
|
|
{
|
|
|
|
queue = gimp_object_queue_new (progress);
|
|
|
|
progress = GIMP_PROGRESS (queue);
|
|
|
|
|
|
|
|
gimp_object_queue_push_list (queue, list);
|
|
|
|
}
|
2006-05-21 19:32:41 +08:00
|
|
|
|
2015-06-26 19:35:07 +08:00
|
|
|
if (list->next)
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
{
|
|
|
|
gimp_image_undo_group_start (image, GIMP_UNDO_GROUP_TRANSFORM,
|
|
|
|
C_("undo-type", "Transform Items"));
|
|
|
|
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
Bug 795410 - Deleting a layer group and then undoing the deletion ...
... raises a CRITICAL
gimp_item_{start,end}_move() currently serves two different
purposes: It is used by GimpLayer to suspend/resume mask resizing
of the layer's ancestors; this is necessary whenever an operation
on a layer might affect the size of its ancestors. It is also used
by GimpGroupLayer to suspend/resume its own mask resizing; this, on
the other hand, is only necessary before applying one of the
transformation functions to the group, so that mask modification is
handled by GimpLayer. In other words, the effects of
gimp_item_{start,end}_move() on group layers are only necessary in
a subset of the cases in which these functions are used.
While in itself this isn't a problem, it does cause issues when
removing a group layer: gimp_image_remove_layer() calls
gimp_item_start_move() before removing the layer, and
gimp_item_end_move() afterwards. While the former function is
called while the layer is still attached to the image, the latter
function is called after the layer is no longer attached. Since
GimpGroupLayer pushes an undo step in response to these calls, only
the call to start_move() results in an undo step, while the call to
end_move() doesn't, resulting in an unbalanced
GIMP_UNDO_GROUP_LAYER_START_MOVE undo step on the stack. This
causes problems when undoing the operation.
Add gimp_item_{start,end}_transform() functions, and corresponding
GimpItem::{start,end}_transform() virtual functions, which are more
specialized versions of gimp_item_{start,end}_move(), which should
be used instead of the former before/after transforming an item; in
other cases, such as when removing ot reordering an item,
gimp_item_{start,end}_move() should still be used. The default
implementation of GimpItem::{start,end}_transform() calls
gimp_item_{start,end}_move(), respectively, so subclasses that
override these functions don't have to do that themselves.
In GimpGroupLayer, override GimpItem::{start,end}_transform(),
instead of GimpItem::{start,end}_move(), for the same purpose of
suspending mask resize. This avoids these functions from being
called when removing a layer group, fixing the bug.
2018-04-22 15:39:40 +08:00
|
|
|
gimp_item_start_transform (GIMP_ITEM (l->data), TRUE);
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
}
|
2006-05-21 19:32:41 +08:00
|
|
|
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
app: use GimpObjectQueue in lots of places
Use GimpObjectQueue, added in the previous commit, in various
instances where we perform an action on a set of objects. This
improves progress reporting, by using a single progress for the
entire operation, rather than reporting the progress of each object
individually, and by taking the relative cost of each object into
account, instead of assuming a uniform cost for all objects.
In particular, this affects the various whole-image operations
(i.e., transformations and color conversions), operations on linked
items, and operations on layer groups. This also affects layers
with masks, whose progress is now reported together instead of
individually.
Additionally, this commit fixes erroneous group-layer mask cropping
during undo when resizing the image, by properly calling
{start,end}_move() on all the resized layers before starting the
operation, and when scaling the image, by only scaling top-level
layers, and letting group layers scale their children themselves.
2018-03-25 22:18:46 +08:00
|
|
|
{
|
|
|
|
if (queue)
|
|
|
|
gimp_object_queue_pop (queue);
|
|
|
|
|
|
|
|
gimp_item_transform (GIMP_ITEM (l->data), context,
|
|
|
|
matrix, direction,
|
|
|
|
interpolation_type,
|
|
|
|
clip_result, progress);
|
|
|
|
}
|
2006-05-21 19:32:41 +08:00
|
|
|
|
2015-06-26 19:35:07 +08:00
|
|
|
if (list->next)
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
{
|
|
|
|
for (l = list; l; l = g_list_next (l))
|
Bug 795410 - Deleting a layer group and then undoing the deletion ...
... raises a CRITICAL
gimp_item_{start,end}_move() currently serves two different
purposes: It is used by GimpLayer to suspend/resume mask resizing
of the layer's ancestors; this is necessary whenever an operation
on a layer might affect the size of its ancestors. It is also used
by GimpGroupLayer to suspend/resume its own mask resizing; this, on
the other hand, is only necessary before applying one of the
transformation functions to the group, so that mask modification is
handled by GimpLayer. In other words, the effects of
gimp_item_{start,end}_move() on group layers are only necessary in
a subset of the cases in which these functions are used.
While in itself this isn't a problem, it does cause issues when
removing a group layer: gimp_image_remove_layer() calls
gimp_item_start_move() before removing the layer, and
gimp_item_end_move() afterwards. While the former function is
called while the layer is still attached to the image, the latter
function is called after the layer is no longer attached. Since
GimpGroupLayer pushes an undo step in response to these calls, only
the call to start_move() results in an undo step, while the call to
end_move() doesn't, resulting in an unbalanced
GIMP_UNDO_GROUP_LAYER_START_MOVE undo step on the stack. This
causes problems when undoing the operation.
Add gimp_item_{start,end}_transform() functions, and corresponding
GimpItem::{start,end}_transform() virtual functions, which are more
specialized versions of gimp_item_{start,end}_move(), which should
be used instead of the former before/after transforming an item; in
other cases, such as when removing ot reordering an item,
gimp_item_{start,end}_move() should still be used. The default
implementation of GimpItem::{start,end}_transform() calls
gimp_item_{start,end}_move(), respectively, so subclasses that
override these functions don't have to do that themselves.
In GimpGroupLayer, override GimpItem::{start,end}_transform(),
instead of GimpItem::{start,end}_move(), for the same purpose of
suspending mask resize. This avoids these functions from being
called when removing a layer group, fixing the bug.
2018-04-22 15:39:40 +08:00
|
|
|
gimp_item_end_transform (GIMP_ITEM (l->data), TRUE);
|
app: add gimp_item_{start,end}_move()
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.
2018-02-05 23:59:28 +08:00
|
|
|
|
|
|
|
gimp_image_undo_group_end (image);
|
|
|
|
}
|
app: use GimpObjectQueue in lots of places
Use GimpObjectQueue, added in the previous commit, in various
instances where we perform an action on a set of objects. This
improves progress reporting, by using a single progress for the
entire operation, rather than reporting the progress of each object
individually, and by taking the relative cost of each object into
account, instead of assuming a uniform cost for all objects.
In particular, this affects the various whole-image operations
(i.e., transformations and color conversions), operations on linked
items, and operations on layer groups. This also affects layers
with masks, whose progress is now reported together instead of
individually.
Additionally, this commit fixes erroneous group-layer mask cropping
during undo when resizing the image, by properly calling
{start,end}_move() on all the resized layers before starting the
operation, and when scaling the image, by only scaling top-level
layers, and letting group layers scale their children themselves.
2018-03-25 22:18:46 +08:00
|
|
|
|
|
|
|
g_clear_object (&queue);
|
2006-05-21 19:32:41 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_image_item_list_get_list:
|
2007-08-14 23:44:02 +08:00
|
|
|
* @image: An @image.
|
|
|
|
* @type: Which type of items to return.
|
|
|
|
* @set: Set the returned items are part of.
|
2006-05-21 19:32:41 +08:00
|
|
|
*
|
2007-08-14 23:44:02 +08:00
|
|
|
* This function returns a #GList of #GimpItem<!-- -->s for which the
|
|
|
|
* @type and @set criterions match.
|
2006-05-21 19:32:41 +08:00
|
|
|
*
|
2015-06-29 05:48:47 +08:00
|
|
|
* Return value: The list of items.
|
2006-05-21 19:32:41 +08:00
|
|
|
**/
|
|
|
|
GList *
|
2016-05-20 05:51:44 +08:00
|
|
|
gimp_image_item_list_get_list (GimpImage *image,
|
2006-05-21 19:32:41 +08:00
|
|
|
GimpItemTypeMask type,
|
|
|
|
GimpItemSet set)
|
|
|
|
{
|
2009-08-02 23:44:05 +08:00
|
|
|
GList *all_items;
|
2006-05-21 19:32:41 +08:00
|
|
|
GList *list;
|
|
|
|
GList *return_list = NULL;
|
|
|
|
|
|
|
|
g_return_val_if_fail (GIMP_IS_IMAGE (image), NULL);
|
|
|
|
|
|
|
|
if (type & GIMP_ITEM_TYPE_LAYERS)
|
|
|
|
{
|
2009-08-02 23:44:05 +08:00
|
|
|
all_items = gimp_image_get_layer_list (image);
|
|
|
|
|
|
|
|
for (list = all_items; list; list = g_list_next (list))
|
2006-05-21 19:32:41 +08:00
|
|
|
{
|
|
|
|
GimpItem *item = list->data;
|
|
|
|
|
2015-06-29 05:48:47 +08:00
|
|
|
if (gimp_item_is_in_set (item, set))
|
2006-05-21 19:32:41 +08:00
|
|
|
return_list = g_list_prepend (return_list, item);
|
|
|
|
}
|
2009-08-02 23:44:05 +08:00
|
|
|
|
|
|
|
g_list_free (all_items);
|
2006-05-21 19:32:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (type & GIMP_ITEM_TYPE_CHANNELS)
|
|
|
|
{
|
2009-08-02 23:44:05 +08:00
|
|
|
all_items = gimp_image_get_channel_list (image);
|
|
|
|
|
|
|
|
for (list = all_items; list; list = g_list_next (list))
|
2006-05-21 19:32:41 +08:00
|
|
|
{
|
|
|
|
GimpItem *item = list->data;
|
|
|
|
|
2015-06-29 05:48:47 +08:00
|
|
|
if (gimp_item_is_in_set (item, set))
|
2006-05-21 19:32:41 +08:00
|
|
|
return_list = g_list_prepend (return_list, item);
|
|
|
|
}
|
2009-08-02 23:44:05 +08:00
|
|
|
|
|
|
|
g_list_free (all_items);
|
2006-05-21 19:32:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (type & GIMP_ITEM_TYPE_VECTORS)
|
|
|
|
{
|
2009-08-02 23:44:05 +08:00
|
|
|
all_items = gimp_image_get_vectors_list (image);
|
|
|
|
|
|
|
|
for (list = all_items; list; list = g_list_next (list))
|
2006-05-21 19:32:41 +08:00
|
|
|
{
|
|
|
|
GimpItem *item = list->data;
|
|
|
|
|
2015-06-29 05:48:47 +08:00
|
|
|
if (gimp_item_is_in_set (item, set))
|
2006-05-21 19:32:41 +08:00
|
|
|
return_list = g_list_prepend (return_list, item);
|
|
|
|
}
|
2009-08-02 23:44:05 +08:00
|
|
|
|
|
|
|
g_list_free (all_items);
|
2006-05-21 19:32:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return g_list_reverse (return_list);
|
|
|
|
}
|
2009-08-25 21:36:03 +08:00
|
|
|
|
|
|
|
static GList *
|
|
|
|
gimp_image_item_list_remove_children (GList *list,
|
|
|
|
const GimpItem *parent)
|
|
|
|
{
|
|
|
|
GList *l = list;
|
|
|
|
|
|
|
|
while (l)
|
|
|
|
{
|
|
|
|
GimpItem *item = l->data;
|
|
|
|
|
|
|
|
l = g_list_next (l);
|
|
|
|
|
|
|
|
if (gimp_viewable_is_ancestor (GIMP_VIEWABLE (parent),
|
|
|
|
GIMP_VIEWABLE (item)))
|
|
|
|
{
|
|
|
|
list = g_list_remove (list, item);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return list;
|
|
|
|
}
|
|
|
|
|
|
|
|
GList *
|
2015-06-29 05:48:47 +08:00
|
|
|
gimp_image_item_list_filter (GList *list)
|
2009-08-25 21:36:03 +08:00
|
|
|
{
|
|
|
|
GList *l;
|
|
|
|
|
|
|
|
if (! list)
|
|
|
|
return NULL;
|
|
|
|
|
2015-06-21 03:58:13 +08:00
|
|
|
for (l = list; l; l = g_list_next (l))
|
|
|
|
{
|
|
|
|
GimpItem *item = l->data;
|
|
|
|
GList *next;
|
2009-08-28 01:36:22 +08:00
|
|
|
|
2015-06-21 03:58:13 +08:00
|
|
|
next = gimp_image_item_list_remove_children (g_list_next (l), item);
|
2009-08-25 21:36:03 +08:00
|
|
|
|
2015-06-21 03:58:13 +08:00
|
|
|
l->next = next;
|
|
|
|
if (next)
|
|
|
|
next->prev = l;
|
2009-08-25 21:36:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return list;
|
|
|
|
}
|