GNOME Bugzilla – Bug 731237
Applications using header bars cannot be moved in Wayland session
Last modified: 2014-07-23 09:24:06 UTC
I've been just trying out Gnome 3.12 Wayland on Arch Linux, and noticed that I was unable to move the windows of applications which use header bar (Gnome Tweak Tool, Files, etc.) by "grabbing" the header. However, Gnome Terminal (which doesn't use header bar) was working perfectly.
Try pressing the button and moving a bit slower before your cursor goes off the header bar. Does that fix it?
No, but I noticed that when holding Super (Windows) key pressed, I'm able to grab the window and move it. Also noticed that the "grabbing hand" cursor shows up for a blink, so the window gets the click event, but doesn't switch to grab for some reason.
I'm not completely familiar with Gtk/GNOME development, but I'll have time to look into this at the weekend. Can you give me some basic instructions, where should I start to look in the source code?
The first thing you should do is make sure that the xdg_surface.move request goes by. Try something like: $ WAYLAND_DEBUG=client gtk3-demo And then look at the output. If you don't see "xdg_surface.move" when you click and move on the headerbar, then GTK+ didn't send the move. If you don't see the move, then the bug is most likely in GTK+. If you do see the move, then the bug is most likely in mutter.
Hi, I'm experiencing the same problem with xdg surfaces. All weston clients are not able to move nor resize. The move request is invoked. After quick debuging I found that it's due to meta_wayland_pointer_can_grab_surface in xdg_surface_move - returns false because the pointer->button_count is 1. After removing this part of condition, the move proceeds further, but with no effect. Only resizing starts working (althoug in reverse ward). Also double-click on maximized window's header works. Regards, Marek
Needed to rebuild the gtk+ (because it had old xdg protocol, so the move/resize was broken) but now I can confirm that the same happens with gtk3-demo. Xwayland clients do not suffer from this - they move normally. The coordinates of the window are updated when I'm moving with it, but the window is kept on the same position. This is because meta_compositor_sync_window_geometry calls (not directly) clutter_actor_set_position always with x=0 and y=0, because the rectangle from which are these coordinates is buff_rect which is not updated for wayland windows (I mean the coordinates are not updated in this rect), but for x11 windows it is. Following two patches solved the issue for me. This is a quick solution, I'm not familiar with this enough to know if we should seek for a solution on a higher level. Regards, Marek Chalupa
Created attachment 279307 [details] [review] Remove part of condition with button_count It's needed for the meta_window_move_resize_internal to be called
Created attachment 279308 [details] [review] Use actual position instead of buffer position This makes the wayland window move again
Review of attachment 279308 [details] [review]: No, this is wrong. This needs to be in buffer_rect coordinates. We need to fix up the setting of x/y in buffer_rect.
Review of attachment 279307 [details] [review]: This should be (button_count > 0). We want to make sure nobody can start a move while the button isn't pressed.
Created attachment 279310 [details] [review] Fix pointer condition for grabbibg
Created attachment 279311 [details] [review] Update buffer_rect when moving
Review of attachment 279311 [details] [review]: This is technically wrong, but should be good enough for now until we get set_window_geometry done.
Review of attachment 279310 [details] [review]: Looks good.
Patches were committed a while ago ...