Instead, pass the actions as part of gdk_drag_begin() and insist DND is
always managed.
A new side effect is that gdk_drag_begin() can now return %NULL.
This is the replacement for selection usage.
Backend implementations for X11 (missing support for backwards compat
formats like COMPOUND_TEXT) and Wayland are included.
GTK code should be adapted to use gdk_drop_read_*() functions instead
of gtk_drag_get_data().
This is in preparation of using input streams to show that these
coordinates aren't needed most of the time and can otherwise be saved
during GtkWidget::drag-drop.
Massive changes to OLE2 DnD protocol, which was completely broken before:
* Keep GdkDragContext and OLE2 objects separate (don't ref/unref them
together, don't necessarily create them together).
* Keep IDataObject formats in the object itself, not in a global variable.
* Fix getdata() to look up the request target in its format list, not in the
global hash table
* Create target GdkDragContext on each drag_enter, destroy it on drag_leave,
whereas IDropTarget is created when a window becomes a drag destination
and is re-used indefinitely.
* Query the source IDataObject for its supported types, cache them in the
target (!) context. This is how GTK+ works, honestly.
* Remember current_src_object when we initiate a drag, to be able
to detect later on that the data object is ours and use a
shortcut when querying targets
* Make sure GDK_DRAG_MOTION is only sent when something changes
* Support GTK drag cursors
* Ensure that exotic GTK clipboard formats are registered
(but try to avoid registering formats that can't be used between applications).
* Don't enumerate internal formats
* Ensure that DnD indicator window can't accept drags or receive any kind of input
(use WS_EX_TRANSPARENT).
* Remove unneeded indentation in _gdk_win32_dnd_do_dragdrop()
* Fix indentation in gdk_win32_drag_context_drop_finish()
* Remove obsolete comments in _gdk_win32_window_register_dnd()
* Check for DnD in progress when processing WM_KILLFOCUS, don't emit a grab
break event in such cases (this allows alt-tabbing while DnD is in progress,
though there may be lingering issues with focus after dropping...)
* Support Shell ID List -> text/uri-list conversion, now it's possible
to drop files (dragged from Explorer) on GTK+ applications
* Explicitly use RegisterClipboardFormatA() when we know that the string
is not in unicode. Otherwise explicitly use RegisterClipboardFormatW()
with a UTF8->UTF16 converted string
* Fix _gdk_win32_display_get_selection_owner() to correctly bail
when selection owner HWND is NULL (looking up GdkWindow for NULL
HWND always succeeds and returns the root window - not the intended
effect)
* More logging
* Send DROP_FINISHED event after DnD loop ends
* Send STATUS event on feedback
* Move GetKeyboardState() and related code into _gdk_win32_window_drag_begin(),
so that it's closer to the point where last_pt and start_pt are set
* Use & 0x80 to check for the key being pressed. Windows will set low-order bit
to 1 for all mouse buttons to indicate that they are toggled, so simply
checking for the value not being 0 is not enough anymore.
This is probably a new thing in modern W32 that didn't exist before
(OLE2 DnD code is old).
* Fixed (hopefully) and simplified HiDPI parts of the code.
Also adds managed DnD implementation for W32 GDK backend (for both
OLE2 and LOCAL protocols). Mostly a copy of the X11 backend code, but
there are some minor differences:
* doesn't use drag_window field in GdkDragContext,
uses the one in GdkWin32DragContext exclusively
* subtracts hotspot offset from the window coordinates when showing
the dragback animation
* tries to consistently support scaling and caches the scale
in the context
* Some keynav code is removed (places where grabbing/ungrabbing should
happen is marked with TODOs), and the rest is probably inert.
Also significantly changes the way selection (and clipboard) is handled
(as MSDN rightly notes, the handling for DnD and Clipboard
formats is virtually the same, so it makes sense to handle
both with the same code):
* Don't spam GDK_OWNER_CHANGE, send them only when owner
actually changes
* Open clipboard when our process becomes the clipboard owner
(we are doing it anyway, to empty the clipboard and *become* the owner),
and then don't close it until a scheduled selection request event
(with TARGETS target) is received. Process that event by announcing
all of our supported formats (by that time add_targets() should have
been called up the stack, thus the formats are known; just in case,
add_targets() will also schedule a selection request, if one isn't
scheduled already, so that late-coming formats can still be announced).
* Allow clipboard opening for selection_convert() to be delayed if it
fails initially.
* The last two points above should fix all the bugs about GTK+ rising
too much ruckus over OpenClipboard() failures, as owner change
*is allowed* to fail (though not all callers currently handle
that case), and selection_convert() is asynchronous to begin with.
Still, this is somewhat risky, as there's a possibility that the
code will work in unexpected ways and the clipboard will remain open.
There's now logging to track the clipboard being opened and closed,
and a number of failsafes that try to ensure that it isn't kept open
for no reason.
* Added copious notes on the way clipboard works on X11, Windows and GDK-W32,
also removed old comments in DnD implementation, replaced some of them
with the new ones
* A lot of crufty module-global variables are stuffed into a singleton
object, GdkWin32Selection. It's technically possible to make it a
sub-object of the Display object (the way Wayland backend does),
but since Display object on W32 is a singleton anyway... why bother?
* Fixed the send_change_events() a bit (was slightly broken in one of the
previous iterations)
* Ensure that there's no confusion between selection conversion (an artifact
term from X11) and selection transmutation (changing the data to be W32-compatible)
* Put all the transmutation code and format-target-matching code into gdkselection-win32.c,
now this code isn't spread across multiple files.
* Consequently, moved some code away from gdkproperty-win32.c and gdkdnd-win32.c
* Extensive format transmutation checks for OLE2 DnD and clipboard.
We now keep track of which format mappings are for transmutations,
and which aren't (for example, when formats are passed as-is, or when
a registered name is just an alias)
* Put transmutation code into separate functions
* Ensure that drop target keeps a format->target map for supported formats,
this is useful when selection_convert() is called, as it only receives a
single target and no hints on the format from which the data should
be transmuted into this target.
* Add clear_targets() on W32, to de called by GTK
* Use g_set_object() instead of g_ref_object() where it is allowed.
* Fix indentation (and convert tabs to spaces), remove unused variables
(This commit is cherry-picked from the gtk-3-22 branch)
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Make sure the API reflects the idea that GdkContentFormats is a set
containing mime types. In particular, treat the object itself as a
plural - it's named content format`S' after all - and therefor use
the correct verb form.
Also make GdkContentFormats keep an array instead of a list, now that
it's immutable.
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
Change constructors to reflect that.
While doing so, also add a fallback argument to the cursor constructors,
so it is now possible to create cursors with fallback.
Drop the screen argument from gdk_dnd_find_window_for_screen
and rename the function to gdk_dnd_find_window. The screen
argument does not add anything here since the drag context
is already tied to the display. Update all backends, and
update all callers.
And have a priv->display instead of a priv->screen.
Includes turning gtk_menu_set_screen() into gtk_menu_set_display(),
because that function just forwards to its window.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
5bb12474d9 removed the dnd window movement code to let
the gdk backends handle the window movement instead. While this
works for X11/wayland the win32 backend still uses the unmanaged
interface and expects the window movement to be handled on the gtk
side. This restores the functionality in case the dnd is unmanaged.
This fixes the drag window on Windows being stuck in the top left
corner instead of following the drag position.
https://bugzilla.gnome.org/show_bug.cgi?id=781737
Instead of creating a GtkWindow, connecting to ::draw and drawing the
surface in there, then adding that window to another GtkWindow... just
use a GtkImage. This also gets rid of a bunch of utility functions used
only in gtk_drag_set_icon_surface.
Switch code to use gdk_display_is_composited() instead.
The new code also doesn't use a vfunc to query the property but rather
requires the backend to call set_composited()/set_rgba() to change the
value.
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
In non-composited environments, we were ending up with all-black
drag icons, because nothing was drawing the background of our new
toplevel. Fix this by drawing background when we are not composited.
We don't do this when composited, since we want to allow transparent
icons.
The documentation clearly says that the widget is not destroyed,
but we were in fact failing to keep it alive, since it was still
a child or the icon_window when we destroy that. Fix this by
reparenting the icon_widget out before. Also, deal with the
possibility that the application might destroy the widget
halfway through, for whatever reason.
We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.
In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
Grabbing must stay a bit longer until all other backends than x11/wayland
catch up with GDK DnD, so ignore deprecation flags are used on those. The
uses of GdkDeviceManager can be entirely avoided though.
When this is in use, there's essentially a bunch of dead code here.
When all backends are ported, we'll be able to remove grab/cursor
management plus a bunch of source-side event handlers.
I hadn't noticed the :drop() pseudo state in the CSS4 Selectors
spec when I added this a while ago. This commit renames
GTK_STATE_FLAG_DND to GTK_STATE_FLAG_DROP_ACTIVE and adds
:drop(active) as equivalent to the :dnd pseudo state.
Remove some now unused includes and dead code, and rename
gtk_drag_set_icon_window to gtk_drag_set_icon_widget_internal,
since it is no longer restricted to toplevel windows.
Under Wayland, the compositor does it, so there is no need
for us to move the window ourselves. For X11, we are now
doing the animation from the X11 backend. Trigger that by
calling gdk_drag_drop_done().
What changes here is that we have to keep the icon_window
alive for as long as the drag context exists. Use a weak
reference to do so.
When we start a drag cancel animation, we can just keep the existing
window. The reset was only necessary to convert from cursor icon to
window and we removed the cursor handling.
The Wayland dnd surface must remain in place until the drag
is over. Setting it directly as the hardcoded window of the
widget we construct carries the danger that it might get
destroyed prematurely, e.g. when the application calls
gtk_drag_set_icon_name more than once and we recreate the
widget.
Instead, create a dedicated toplevel, and reparent the widget
into it. To keep the code simple, we use the same approach
under X11 as well, and make it the responsibility of the
GDK dnd code to keep the window position updated. We already
pass the current pointer position to gdk_drag_motion, which
makes this very easy.
As a side-effect of these changes, it is now possible to use
non-toplevel widgets as drag icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748763
The size of icons is a property that is relevant to who is rendering the
icon, not to the icon itself.
Example: Starting a DND operation from an entry icon should cause the
icon to resize (from the entr icon's size to the DND icon size).
Make gtk_icon_helper_ensure_surface() a private function that just
ensures the surface was loaded.
Add gtk_icon_helper_load_surface() that is called by the above function
and the dnd code to actually load the surface.
This is wrong by all accounts there, as we can do no tricks there to show
a "drag failed" animation, which is performed by the compositor itself
on wayland.
The current widget lookup code bails out on insensitive widgets, there's
however legit cases where we want DnD handled by a parent of the insensitive
widget, so just keep going upwards in that case.
We also use now the widget state flags, because get_sensitive() doesn't
propagate across hierarchies, so we could conceivably find a drop site
inside an insensitive widget.
https://bugzilla.gnome.org/show_bug.cgi?id=751793
