Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
In GTK 3 we used to move the popovers around using set_relative_to();
this is gone in GTK 4 and the apparent direct replacement is setting
the target widget as the new parent.
But this requires a lot of careful handling least the popover become
orphan, which gets us ready to crash at any moment.
Since we only care about positioning the popovers relative to a row,
let's use the set_pointing_to() instead of reparenting. Now, the
sidebar is always the parent.
Rename the GtkDropTraget:drop property to :current-drop,
to avoid naming collision with the signal of the same
name.
We leave the old property and getter in place, deprecated
and marked as non-introspectable.
Fixes: #4028
This fixes nautilus crash and perhaps other callers issues.
Nautilus (and sometimes glib) crashes with malformed URI inside of the
bookmarks file .config/gtk-3.0/bookmarks when it has no LABEL.
This is result from the closed glib MR #2065 analysis and agreement.
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2065#note_1091979
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
If multiple nested widgets have drag sources on them, both using bubble
phase, we need to reliably pick the inner one. Both of them will try to
start dragging, and we need to make sure there are no situations where the
outer widget starts drag earlier and cancels the inner one.
Currently, this can easily happen via integer rounding: start and current
coordinates passed into gtk_drag_check_threshold() are initially doubles
(other than in GtkNotebook and GtkIconView), and are casted to ints. Then
those rounded values are used to calculate deltas to compare to the drag
threshold, losing quite a lot of precision along the way, and often
resulting in the outer widget getting larger deltas.
To avoid it, just don't round it. Introduce a variant of the function that
operates on doubles: gtk_drag_check_threshold_double() and use it instead
of the original everywhere.
The GtkPlacesOpenFlags enum is only used in private
API, so move it to private headers. Since we still need
a GType for it, add gtkplacessidebarprivate.h to the
headers we use for generating private enum types. In turn,
this registers the other private enums in that header, so
take the opportunity to fix their naming, and use the
generated types for the corresponding sidebarrow properties.
Fixes: #3337
In 99.9% of all cases, these are just NULL, NULL.
So just do away with these arguments, people can
use the setters for the rare cases where they want
the scrolled window to use a different adjustment.
The leave signal should not take any arguments,
don't pass the GdkDrop. Update the documentation,
fix the emission and update users to match.
This was showing up as crash when dragging files
over the places sidebar.
This is a huge reorganization of GtkDropTarget. I did not know how to
split this up, so it's unfortunately all one commit.
Highlights:
- Split GtkDropTarget into GtkDropTarget and GtkDropTargetAsync
GtkDropTarget is the simple one that only works with GTypes and offers
a synchronous interface.
GtkDropTargetAsync retains the full old functionality and allows
handling mime types.
- Drop events are handled differently
Instead of picking a single drop target and sending all DND events to
it, every event is sent to every drop target. The first one to handle
the event gets to call gdk_drop_status(), further handlers do not
interact with the GdkDrop.
Of course, for the ultimate GDK_DROP_STARTING event, only the first
one to accept the drop gets to handle it.
This allows stacking DND event controllers that aren't necessarily
interested in handling the event or that might decide later to drop
it.
- Port all widgets to either of those
Both have a somewhat changed API due to the new event handling.
For the ones who should use the sync version, lots of cleanup was
involved to operate on a sync API.
First, it should have been a GdkDrop, but even then, proper DND code
should not rely on internals.
It's only been used in an unused signal emission anyway.
