The GimpDockWindow will need to have a GimpContext so add such a
property but call it "gimp-context" for now to avoid clashing with
"context" of GimpDock.
Introduce GimpDockWindow and make GimpDock inherit from it. Right now
it is just a GimpWindow, but window logic from GimpDock and subclasses
will gradually be moved here so that we eventually can make GimpDock a
GtkBin. That in turn will allow us to put several GimpDocks next to
each other in columns, or GimpDocks in an image window.
Don't blindly fill the dest region's alpha channel even if it has
none. Fixes longstanding bug that made things without alpha dropped
to indexed images to arrive broken.
The new functions reall convert the drawable this time, using the
previously renamed convert_tiles functions. Remove tile manager
fiddling from all callers and leave it there only for converting to
indexed.
Rename them from gimp_drawable_convert_foo() to
gimp_drawable_convert_tiles_foo() because they don't convert the
drawable itself, they convert its tiles into passed-in tiles.
In order to allow test cases to test GUI code, add
gimp_init_for_gui_testing() which is like gimp_init_for_testing() but
includes initializations of GUI parts.
* tests.[ch]: initialize base so we have a tile cache and add
parameter "gboolean use_cpu_accel" so we can test stuff both with
and without using CPU features.
* tests/test-layer-grouping.c: changed accordingly. Call g_thread_init()
so the tile cache works (and to be on the safe side in general).
* app/core/gimpgrouplayer.[ch]: add gimp_group_layer_suspend_resize()
and gimp_group_layer_resume_resize() and call them around functions
where all a group's children are transformed (translated, resized
etc). This way we go from the worst case of reallocating the
group's projection tiles once for each child down to exactly one
reallocation.
* app/core/Makefile.am
* app/core/core-enums.[ch]
* app/core/core-types.h
* app/core/gimpimage-undo-push.[ch]
* app/core/gimpgrouplayerundo.[ch]: add new undo class
GimpGroupLayerUndo which implements undos for suspend/resume of
group layers and calls them in reverse order when undoing.
Enable us to have regression testing by introducing a core testing
framework that uses the GLib JUnit-like test library.
Do this by adding a new subdir app/tests that will contain all our
tests (it contains one trivial test already). Also add app/tests.[ch]
with a new function gimp_init_for_testing() so that test cases can
easily setup the core object system.
Will enable it again when I fixed it properly, it's clearly a
non-trivial problem that needs some thinking. Disabled for now because
it causes crashes.
Clean up subsystem linking dependencies by
* Rearranging LDADD entries to better match architectural layers
* Being clear about why we need to pass -u in LDFLAGS some times
* Adding FIXMEs when we have broken dependencies
* Introducing a helper variable so we can share LDADD between
gimp-console and gimp
Don't add layer masks to their layers while loading because a newly
loaded group layer's size doesn't match its mask's size. Instead,
attach all layer masks to their layers using g_object_set_data(), and
add them after all layers have been loaded.
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)
Yes this is pretty lame, but we must prevent write access to these
items under all circumstances, and we have no other way but killing
the plug-in (it should not write to the drawable directly anyway)
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.
A floating selection is always the first layer in the image, but on
XCF loading it is attached *after* all layers are loaded, so the item
paths for child layers read from the XCF are off-by-one in their
toplevel index. Adjust them so everything loads as it should.
* app/xcf/xcf-private.h: add properties PROP_GROUP_ITEM and
PROP_ITEM_PATH
* app/xcf/xcf-save.c: when saving a group layer, save a
PROP_GROUP_ITEM. When saving a child item, save a PROP_ITEM_PATH
which contains the path indices returned by gimp_item_get_path().
* app/xcf/xcf-load.c: when loading a PROP_GROUP_ITEM, replace the
layer that is being loaded by a GimpGroupLayer, also ignore that
layer's hierarchy (it makes no sense to load the tiles of a layer
that's generated from its children). When loading a PROP_ITEM_PATH,
pass the loaded path up to xcf_load_image() so it can add the loaded
layer at the right place in the tree.
This is actually just an intermediate refactoring that uses
gimp_image_get_foo_list() inetad of get_foo_iter(), but it also
sanitizes saving the image's selection (it's now simply added to the
list of channels to save, instead of using some sick code to save it
in the same loop that saves channels), so i want to have this in a
separate commit from actual tree saving/loading.
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.
As when loading channel props (which can replace the GimpChannel by a
GimpSelection), pass a GimpLayer** instead of a GimpLayer* to
xcf_load_layer_props(), so the function can replace the GimpLayer to
load by another type (e.g. GimpGroupLayer).
Add XCF property PROP_LOCK_CONTENT and save/load it for all layers and
channels. Vectors saving needs some refactoring here I'm afraid, so I
ignored it for now.
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.
"lock-content" will be separate from "is-group" soon, so add separate
checks for groups. Also remove some checks that were added to make
wrappers invokable even though the group appeared locked.
New function returns FALSE and sets an appropriate error if invoked on
a group item. Use it from gimp_pdb_get_vectors_stroke() because if we
ever get vectors groups, they will have no strokes.
The idea that group layers count as locked was a bad one, start adding
separate checks for group layers, and refuse to modify them with
distinct error messages.
- gimp_container_tree_view_prepend_toggle_cell_renderer() to
gimp_container_tree_view_add_toggle_cell()
- gimp_container_tree_view_prepend_cell_renderer() to
gimp_container_tree_view_add_renderer_cell()
because "prepend" is an implementation detail, "renderer" is obsolete,
and in the second case it's not "cell renderer" but really a "renderer
cell".
Even though a user can only save to XCF in File->Save, the "All
images" filter shall show all images to allow a user to steal names
from non-XCF images and vice versa for File->Export, so make that
happen.
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.
Call pango_cairo_font_map_new_for_font_type (CAIRO_FONT_TYPE_FT)
instead of pango_cairo_font_map_new ().
This avoids a crash on Windows where the default font map is for
CAIRO_FONT_TYPE_WIN32. For the text tool we want freetype and
fontconfig -based fonts.
This requires using a cairo that includes the freetype backend, and a
pango that has been built against such a cairo. That is not yet the
case for the "official" Windows binaries of cairo and pango, but I
will make it so in the future.
If we didn't click on any cell, but on empty space in the expander
column of a row that has children, let GtkTreeView process the button
press to maybe handle a click on an expander.
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.
Don't recursively duplicate all items. Instead, just duplicate the
items in the toplevel image containers, because group items duplicate
their children correctly all by themselves.
New function takes a GList of items as returned by
gimp_image_item_list_get_list() and can filter out items that:
- have lock_content set to TRUE.
- are children of items that are also in the list (to avoid
transforming group items *and* their children, because
the group items already do that for us).
Insert a gegl:translate node into the group layer's projection
graph. Produces identical results as the legacy projection now, but is
not yet switched on by checking View->Use Gegl.
Flipping horizontally and vertically as well as rotating by multiples
of 90° works fine now for group layers, enable it even though they
appear locked. It seems that group == locked idea is not as allmighty
as i thought :(
Add implementations for GimpItem::translate(), scale(), resize(),
flip(), rotate() and transform(). Simply transform all children, the
group layer will automatically update itself. Also transform the layer
mask.
Implement the GimpProjectable interface and keep a GimpProjection
around that projects the GimpDrawableStack of our children. Propagate
the childrens' "update" signals to our own "update" signal so our
parent projection picks up all changes.
Add/Subtract the projectable's offset whenever we go from coordinates
from our public interface (which are always image coordinates) and
coordinates in out internal tile pyramid (wihch always starts at 0,0).
The Gegl projection still needs an offset node that is missing.
Also, connect to the projectable's "update" signal using
g_signal_connect_closure_by_id() instead of simply g_signal_connect(),
so we really connect to the signal of the GimpProjectable interface
and not to the "update" signal of GimpDrawable (which is a conflict
that will happen on group layers).
Add GimpProjectable::get_offset() and gimp_projectable_get_offset()
which returns the offset of the projectable in image coordinates, so
we can have projections that act as a viewport onto things that live
in image coordinates.
Add gimp_item_can_lock_content() and gimp_layer_can_lock_alpha() which
return TRUE unless the item is a grop (has children), because group
items will be considered to have lock_content always TRUE and
lock_alpha always FALSE.
* app/plug-in/gimppluginprocedure.[ch]
(gimp_plug_in_procedure_get_sensitive): change GimpImageType
parameter to GimpDrawable and do the type check internally.
* app/actions/plug-in-actions.c (plug_in_actions_update): pass the
active drawable instead of its type.
We have no reason to believe that the original layer names when
importing multi-layered images are not good enough, so stop adding the
filename as a prefix to the names.
* app/pdb/gimppdb-utils.[ch]: add "gboolean writable" to
gimp_pdb_layer_is_text_layer() because that's called on
all text layers anyway.
* tools/pdbgen/pdb/text_layer.pdb
* tools/pdbgen/pdb/vectors.pdb: pass TRUE if we want to modify the layer.
* app/pdb/text-layer-cmds.c
* app/pdb/vectors-cmds.c: regenerated.
Remove GimpTool::initialize() implementation again and check for the
drawable being locked in GimpTool::button_press() so we can't paint if
the tool has been used before on the same drawable when it was
unlocked.
* app/pdb/gimppdb-utils.[ch]: add "gboolean writable" parameter to
gimp_pdb_item_is_attached() because this function is called on
almost all items where a check for locked is needed.
* tools/pdbgen/pdb/*.pdb: pass writable = TRUE in all checks for items
that are modified. Add explicit calls to gimp_pdb_item_is_writable()
in some rare cases.
* app/pdb/*-cmds.c: regenerated.
Check whether the drawable to edit is locked in GimpTool::initialize()
and bail out with an appropriate error if it is. This currently
prevents cloning from locked drawables, will fix that later.
* app/widgets/gimpitemtreeview.[ch]: add class members for the lock
content button's icon, tooltip and help_id and use them when
creating the button. Create the button in constructor() instead of
init() so we have access to our real class structure without the
need for a custom get_type() function.
* app/widgets/gimpdrawabletreeview.c: configure the button as "Lock pixels".
* app/widgets/gimpvectorstreeview.c: configure it as "Lock path strokes".
Took patch from Martin Nordholts and ported it to add a "lock-content"
property, signal and API in the same way as it's done for "visible"
and "linked".
- new API to add widgets to a box of options, for stuff like the paint
mode menu and opacity scale. Set it sensitive automatically and
update its spacings in GtkWidget::style_set().
- new API to get a hbox for "lock" toggles, for stuff like lock
pixels and lock alpha.
This reverts commit d2e1f2ac74. If we
keep the layer group button in 2.7.0 people will expect layer groups
to fully work and get mad when that is not the case. We can enable it
again after the release.
Add support for having obsolete data resources. An obsolete resource
is not shown in the UI or managed in any way, but it will be
considered when plug-ins requests resources. This in order to maintain
backwards compatibility for plug-ins.
Since Ctrl+E previously meant something harmless, don't use that
keyboard shortcut for the destructive command 'File->Overwrite'. We
still keep Ctrl+E for 'File->Export to' though, and we do this by
having 'File->Overwrite' as a separate GtkAction with its own keyboard
shortcut slot.
Don't reuse the GeglProcessor as it can't handle dirty rects when
painting in GIMP, and this makes it harder to make GEGL-wise progress
in other parts of GIMP.
* app/core/gimpimage.[ch]: rename all gimp_image_reposition_foo() to
gimp_image_reorder_foo() and added "new_parent" parameters. Factor
out calculating of the item's new container and index to a utility
function.
* app/core/core-enums.[ch]: rename the REPOSITION undos to REORDER.
* app/core/gimpimage-undo-push.[ch]
* app/core/gimpchannelpropundo.[ch]
* app/core/gimplayerpropundo.[ch]
* app/vectors/gimpvectorspropundo.[ch]: change accordingly. Remember
the old parent item in all item reorder undos.
* app/widgets/gimpitemtreeview.h: change GimpReorderItemFunc prototype
accordingly.
* app/widgets/gimpchanneltreeview.c
* app/widgets/gimplayertreeview.c
* app/widgets/gimpvectorstreeview.c (class_init): follow image API
name changes.
* app/widgets/gimpitemtreeview.c (gimp_item_tree_view_drop_viewable):
implement reordering of items between groups.
* app/widgets/gimpcontainertreeview.c
(gimp_container_tree_view_reorder_item): fix to reorder the item
within its level of the tree (unrelated to above changes, but needed
to make them work).
* app/widgets/gimpcontainertreeview-dnd.c
(gimp_container_tree_view_real_drop_possible): support DND within a
tree and make sure a group item is not dropped into itself.
* app/widgets/gimpitemtreeview.c (gimp_item_tree_view_drop_viewable):
implement intra-container reordering within all branches; print a
message for inter-container reordering because that's not yet
implemented in the core.
The new functions figures if one viewable is another's parent or
grandparent or grandgrand... Note that unlike gtk_widget_is_ancestor(),
this function has its parameters in the right order.
A tree-enabled replacement for gimp_container_add,remove_handler(),
slightly more sane to a degree that makes me think it could replace
GimpContainer's own handler stuff. Public API consists of two
function:
- gimp_tree_handler_connect() which connects recursively to a specific
signal of all items in a container tree.
- gimp_tree_handler_disconnect() is just a wrapper around unrefing the
handler, but makes sure that dispose() is really executed (which
actually disconnects things).
Martin Nordholts