Another attempt to fix paste/drop positions for good.
Paste/drop target is either the selected area of a drawable, the
drawable itself, or the image:
- if the paste is larger than the target, center on the target
- if there is a viewport, and the viewport intersects with the
target, center on the intersection
- otherwise, center on the target
Finally, if we did viewport-centered pasting, make sure the paste is
as completely within image bounds as possible.
(cherry picked from commit eda6fa1c14)
Fix this and other issues more globally by moving the logic that
formats the image's display name into the GimpImage object, and return
the properly formatted name, e.g. "Foo.xcf", or "[Foo] (imported)"
from gimp_image_get_display_name().
Also add gimp_image_get_display_path() which returns the full path
instead. Use the two functions for formatting the image title, and
apply various other fixes that make sure the UI always uses the same
string to identify the image.
Call gimp_object_name_changed() whenever the save/export status
changes, so the image's cached display name and path get cleared.
(cherry picked from commit 220b28677b)
This got lost during layer group porting, reimplement it, but restrict
"all layers" to the clicked layer's branch in the tree.
(cherry picked from commit 67b5a509b6)
gimp_layer_get_opacity_at(): use gimp_item_is_visible() not
get_visible() so we use the layer's effective visibility.
(cherry picked from commit 4d1173570a)
In fact, it broke much more than that because the way XCF loading
replaced the image's mask prevented the image's "mask-changed" signal
from ever being emitted. Add private API gimp_image_take_mask() which
properly sets the mask and use it for image construction and the XCF
selection loading hack.
(cherry picked from commit ab4c613a70)
gimpdir goes to ~/Library/Gimp/x.y
thumbnails go to ~/Library/Caches/org.freedesktop.thumbnails
The thumbnail location is not standardized yet, but is the only
location that makes sense. Also fix user install to search old
gimpdirs to migrate in both Library and the classic location.
Remove the obsolete CABON_CFLAGS from all makefiles.
(cherry picked from commit 9112d68488)
Add gimp_tag_has_prefix() and use it in GimpTagEntry when completing
patrially entered tag names, and fix two uses of strcmp() in
GimpTagPopup to use gimp_tag_compare_with_string().
(cherry picked from commit 30b4fe8510)
so the image's "foo-moved" signals are emitted and the display can
follow. Moving them around manually was needed before the displayed
guides and sample points were proper views of the resp. core objects.
to silence valgrind
==12105== Conditional jump or move depends on uninitialised value(s)
==12105== at 0x6B069C: gimp_data_set_folder_tags (gimp/app/core/gimpdata.c:885)
==12105== by 0x6B155E: gimp_data_factory_load_data (gimp/app/core/gimpdatafactory.c:922)
==12105== by 0x64F34D0: gimp_datafiles_read_directories (gimp/libgimpbase/gimpdatafiles.c:155)
==12105== by 0x6B1293: gimp_data_factory_data_load (gimp/app/core/gimpdatafactory.c:354)
==12105== by 0x6B1E1C: gimp_data_factory_data_init (gimp/app/core/gimpdatafactory.c:239)
==12105== by 0x6871D2: gimp_restore (gimp/app/core/gimp.c:952)
==12105== by 0x47EABA: app_run (gimp/app/app.c:217)
==12105== by 0x47E64D: main (gimp/app/main.c:440)
==12105== Uninitialised value was created by a stack allocation
==12105== at 0x6B1190: gimp_data_factory_data_load (gimp/app/core/gimpdatafactory.c:319)
GimpData: add gimp_data_set_folder_tags() and remove the tag logic
from gimp_data_set_filename(). The function gets the toplevel data
directory passed so it knows where to stop assigning tags.
GimpDataFactory: when loading data, keep track of the currently
processed data hierachy's toplevel directory, and pass it to above new
function. Also make sure obsolete files don't get folder-tagged.
Previously flag writable was used. This caused ritable and editable
brushes to sort first. This was not clearly understood criteria.
Now user brushes in writable folders are sorted first.
- move the code that sets the tool options' "defined" and "serialize"
properties from GimpToolInto to GimpToolOptions so they are always
set correctly.
- make GimpToolOptions fix broken serialized NULL tools automatically.
- make sure a GimpToolPreset's tool options always has a tool set. If all
fails, set a NULL tool explicitly and let the logic in GimpToolOptions
find the right tool.
- set GimpToolPreset's "use" booleans to FALSE for context properties
that have no effect on the tool.
- set GimpToolPresetEditor's toggle insensitive for these properties.
Make sure obsolete files are immutable, and propagate a folder's
"writable" state into its subfolders. Also clean up the function's
control flow to not fry the reader's brain.
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.
