Introduced two virtual functions to a GimpViewable
'set_expanded' and 'get_expanded'
and a PROP_GROUP_ITEM_FLAGS to load/save the expanded state
of layer_groups and use them.
Fix typo in gimp_drawable_fs_update(): use the drawable's x and y
offsets to calculate the intersection with the fs' update area, and
not the y offset for both axes.
Fix the commit two down in the log: a layer can be a floating
selection even if it's not attached to anything (when it is on the
undo stack). Don't detach it if it is not the underlying drawable's
current fs.
When the layer is a floating selection, its source node is being
hijacked by the underlying drawable to be composited on top of it.
This can happen before the layer's own layer node is being created; in
this case we must not add the source node to the layer node. Detaching
the floating selection in any way will fix up things later.
We crash when closing an image that has a floating selection and the
GEGL projection is being used. Detach the floating selection when
either the FS or the drawable it's attached to are disposed. This fix
only makes it crash later, but makes sense as separate commit.
Instead of getting the floating selection from the image. Change
gimp_drawable_has_floating_sel() to get_floating_sel() and remove the
"floating_sel" parameter from gimp_drawable_deatch_floating_sel().
This cleanup is one more step towards sanitizing floating selections,
and makes the crash fix in the next commit much much simpler.
It's likely that the removed call and function were causing
random drawing artefacts, but as this was once in a blue
moon bug, I have just a guess to go by however, testing
revealed no regressions, so pushing.
Make gimp_image_get_uri() and gimp_image_get_filename() behave as in
the GIMP 2.6 days. Add new functions gimp_image_get_xcf_uri(),
gimp_image_get_exported_uri() and gimp_image_get_imported_uri().
Add GimpWindowingStrategy with create_dockable_dialog() and use it in
dialogs_create_dockable_cmd_callback(). There are two implementations:
GimpSingleWindowStrategy and GimpMultiWindowStrategy. Depending on the
window mode, we want new dockables to appear in different places when
created. In single-window mode, they should appear inside the single
image window. In multi-window mode, a new dock window is created.
- start_stroke()/finih_stroke() -> begin_stroke()/end_stroke()
- process_event_queue() -> process_stroke()
- GimpMotionBuffer::motion() -> GimpMotionBuffer::stroke()
- add GimpMotionBuffer::hover() and process_hover()
- remove push_event_history() and pop_event_queue() from API
The thing works like this:
- Motion events are continuously fed into the buffer using motion_event()
- begin_stroke()/end_stroke() correspond to BUTTON_PRESS/BUTTON_RELEASE,
the period between them is a "stroke"
- If motion_event() returns TRUE, we request "stroke" signals by calling
process_stroke() and "hover" signals by calling process_hover()
and emit the buffer's "motion" signal when a motion is supposed
to happen. In GimpDisplayShell, connect to GimpMotionBuffer::motion()
and call the tool.
