When the projectable's size or image type changes, stop the idle
renderer and remove all queued update area because everything needs to
be re-rendered anyway. Also honor the projectable's offset when
invalidating the entire projection after clearing the pyramid.
The optimization here which would change only the group layer's offset
if the extents of the union of its children has not changed is
completely bogus. That case can only happen if one of the chldren was
moved in a way that does not change the extents of all children's
union, but this doesn't mean that the childrens' positions relative to
each other have not changed.
Instead, invalidate the entire projection to at least avoid constant
reallocation of the tile pyramid.
Found by group layer testing hero Tobias Jakobs.
(will have to optimize real translations of the entire group (or of the
only child in the group) differently)
Having a function that only abstracts whether there is an active
layer or not is pretty useless. This also doesn't make the code in
selection_generate_segs() more complex but rather more obvious.
When attaching/detaching a floating selection to/from its drawable,
connect/disconnect the floating selection's "update" signal and update
the drawable in the callback, because changes to the floating
selection affect the drawable and not the projection directly. Fixes
floating selection compositing in layer trees and is the right thing
to do anyway.
The opposite of gimp_item_get_path(), just that it doesn't return an
item, it returns a parent item and an index that can be used to add
the item to an item tree.
Use the new API whenever we want to determine the item's effective
lock state (whether we can write to the item's content or not). Use
gimp_item_get_lock_content() only in code that actually deals with
*this* item's locked state, which is only the PDB wrappers and GUI to
modify the flag on the item itself.
Begin to consider GimpObject::name as private and always use
gimp_object_get_name(). Change gimp_object_get_name() to take an
untyped pointer so we don't have to do so awfully many casts. There is
a runtime check for the type inside the function anyway.
Make sure a group layer really emits all needed size change signals
when children get added and removed, so the group layer above it can
also update itself based on these signals. Spotted (again) by tobi.
Now that group layers properly implement GimpItem::resize(), ::flip(),
::rotate() and ::scale(), we can go back to just transforming the
toplevel container of layers in the image. Left in and/or added some
special cases anyway, like when resizing sets of layers along with the
image is requested.
The only purpose of this change is to avoid having the "update"
signal twice on GimpGroupLayer (from GimpDrawable and from
GimpProjectable). Switch back to normal g_signal_connect()
in the projection.
This also (really this time) fixes nested group layers. There were
cases when the outer group layer didn't properly resize itself because
gimp_drawable_set_tiles() on the inner group layer failed to emit
notify::width and notify::height.
Sets the "width" and "height" properties and emits notifications and
"size-changed" if anything has changed. This in only to be used by
functions that actually resize the item, it does not scale/resize
anything.
* make internal merge functions aware of the container to merge and
its parent layer.
* git rid of some cruft in gimp_image_merge_down().
* merge down works within one container (naturally) and needs:
- the uppper layer not to be a group
- the lower layer to be writable
* fix action sensitivity accordingly.
