This patch does following things for this purpose:
* Adds intrernal flag to GimpTag api
* Modifies GimpData gimp_data_set_filename to use the last element
of the path, unless blacklisted, as internal tag for the resource.
* Modify tag cache to not save internal tags
* Removes a check for existing tags when objects are added to tag cache
It was never disconnecting from any of the src_container objects'
signals.
GimpFilteredContainer: unref the src_container in finalize() instead
of dispose() because the parent dispose() impl now needs it via
calling gimp_container_clear().
GimpTaggedContainer: implement GimpContainer::clear() and disconnect
from all the src_container objects' signals.
but don't fix it for item trees yet (refactoring only). Kill the
"exclusive liked" function which only existed because it was so easy
to have, but was always utterly useless. Prove me wrong and I will
revive it.
The output of transforms can result in the transformed points being
passed out of order to gimp_transform_resize_crop(). The Jarvis march
method is used to find the convex hull of the points to get them in a
known order, before performing the crop operation.
Static analysis found a bug in the Jarvis march algorithm, but when we
looked at the code, we could no longer follow it. So a slightly
rewritten version is committed here without the static analysis bug.
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.
Michael Natterer