GNOME Bugzilla – Bug 768128
with wayland and gtk_window_begin_move_drag there's apparently no way to track where the window is
Last modified: 2018-04-15 00:28:23 UTC
Created attachment 330476 [details] floating toolbar example With the attached example with GDK_BACKEND=x11 when I click on the window and drag it around I get configure-events which I can use to track the current location of the window. Under wayland I don't get anything useful. The use case is floating toolbars in LibreOffice which can be docked when the toolbar is dragged over a docking point.
There is no global coordinate in Wayland.
There is no way of doing this currently. The closest thing is drag-and-drop, but I imagine that is not enough. Maybe we could add some drag-n-drop-surface thing that works like a combination of drag-n-drop and interactive move.
I believe this is basically wontfix ?
It depends if we feel the use case is important enough to fix. Thinking more about it, if these dialogs are not expected to need automatic compositor driven positioning (to keep it within the monitor work/monitor area), they could just be turned into subsurfaces. Moving could be done completely client side, and it'd know the relative positions of everything, since the client would position things itself. If so, should such behaviour be part of GTK+ or should the application deal with it itself?
(In reply to Caolan McNamara from comment #0) > [...] > The use case is floating toolbars in LibreOffice which can be docked when > the toolbar is dragged over a docking point. If I understand correctly, those floating toolbars in LO can be detached to become floating, or re-attached to the main client window as a given location where they become part of the main window again. That makes me think of the (now deprecated) GtkHandleBox: https://developer.gnome.org/gtk3/stable/GtkHandleBox.html
(In reply to Olivier Fourdan from comment #5) > > If I understand correctly, those floating toolbars in LO can be detached to > become floating, or re-attached to the main client window as a given > location where they become part of the main window again. > > That makes me think of the (now deprecated) GtkHandleBox: > > https://developer.gnome.org/gtk3/stable/GtkHandleBox.html Yeah, its the same concept as GtkHandleBox, that's broken since 3.20 on all platforms (http://trac.wxwidgets.org/ticket/17539) and never(?) worked under wayland. I'll just disable the possibility of floating toolbars under wayland I think, anything else either won't work or be some unusual fragile edge case
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new