[Wayland-bugs] [Bug 697855] Implement DnD in wayland
gtk+ (bugzilla.gnome.org)
bugzilla at gnome.org
Thu Aug 28 11:10:59 PDT 2014
https://bugzilla.gnome.org/show_bug.cgi?id=697855
gtk+ | Backend: Wayland | 3.8.x
--- Comment #40 from Carlos Garnacho <carlosg at gnome.org> 2014-08-28 18:10:54 UTC ---
(In reply to comment #37)
> Review of attachment 284713 [details]:
>
> Still slightly confused about why this is necessary - don't all wayland events
> carry the full 'current input state', including both buttons and modifiers ?
Hmm, trying to remember the reasons why this was necessary, and I'm thinking
this is some miscellaneous thing I found, having text selection and other
gestures stuck after pressing a key because
gdk_window_get_device_position/gdk_device_get_state would return masks with no
buttons. But as far as I can look now, shouldn't be hit too often on DnD, so
maybe best to treat this separately.
In any case, wayland input listeners are fairly light in information each, it
is up to gdk to maintain positions/modifiers/axes/scroll diffs the
GdkWaylandDeviceData so it can compose GdkEvents, and there's also
gdk_device_get_state() and friends to cater for...
(In reply to comment #38)
> Review of attachment 284714 [details]:
>
> ::: gdk/wayland/gdkselection-wayland.c
> @@ +259,3 @@
> +
> + return display->selection;
> +}
>
> maybe turn this into a gdk_wayland_selection_new() that gets calls from the
> display code, plus
> a gdk_wayland_display_get_selection() to obtain the singleton ?
>
> Looks slightly odd to have this poked directly into the display here, but have
> the free call on the display side.
Yeah I agree, this turned out a bit odd.
(In reply to comment #39)
> Review of attachment 284715 [details]:
>
> What I find slightly confusing here is that we seem to be dealing with
> CLIPBOARD, GDK_SELECTION and GdkWaylandSelection as atoms here - one too many,
> or is GDK_SELECTION different from the other two, since it is used as a
> property name, not as a selection ?
Exactly, GDK_SELECTION is just the "property" used to store the data through
gdk_property_change(). There's some atom internship madness going on in the
patch though... I'll clean up so we can compare with eg. selections[CLIPBOARD]
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the Wayland-bugs
mailing list