GNOME Bugzilla – Bug 735756
Relative window positioning doesn't work
Last modified: 2015-12-03 15:19:26 UTC
Created attachment 284945 [details] example I'm trying to position one window relative to another one using jhbuild gtk + wayland + weston. (see the attached example) What I expected (under wayland): * get_origin() of the top most window returns 0,0 * moving a window that is set transient for the top one can be moved relative using origin_parent + offset (like under X11, Windows, except origin is always 0,0) What happens: * The transient window doesn't move at all on gtk_window_move() When I initially ported to wayland during 3.11 this used to work as expected. If this is for some reason not supported anymore, how can I position windows relative to one another?
Toplevels in wayland don't have a notion of global position that is exposed to the application - thats why you see the origin reported as 0,0. Other surface types, such as popups and subsurfaces allow some level of control of the positioning relative to their parent surface. See https://git.gnome.org/browse/gtk+/tree/gdk/wayland/gdkwindow-wayland.c#n938 for more. There may very well be a bug here, though.
I get the same result for popups.
gdk_window_wayland_move_resize doesn't do anything on child surfaces. And I don't see anything in wayland to move a surface ..?
Jasper asked for use cases, here are some: * Modal dialogs currently get placed randomly on the screen while making the parent non responsive. I'd argue they shouldn't. * Same for windows that are set to be place on the center of the parent (in my case clicking on a album cover opens a bigger version centered on the window, or preference windows) * I have a custom tooltip implementation: https://i.imgur.com/QE0ZdvM.gif No idea how to port that. * I have a slider in a window that pops up next to a button: https://i.imgur.com/KNotPgA.png Also no idea. Positioning: I like the current solution that the top most parent defines the fake root. This makes offset calculations work on both X11 and wayland. Window dragging: * Dragging the modal dialog could move the parent and dragging the parent could move the dialog. * Moving preference window should not move the parent and vice versa * A popover like widget should move with the parent, but might depending on the use case be movable independent of the parent. So as a result each window could specify if it should move with the parent and if the parent should move with the window. Resizing: I don't see any problems there.
(In reply to comment #4) > Jasper asked for use cases, here are some: > > * Modal dialogs currently get placed randomly on the screen while making the > parent non responsive. I'd argue they shouldn't. Yeah, this is because we don't have any way of marking a window as a "modal dialog", so you won't get the center-attachment behavior. This is something we should fix, I think. > * Same for windows that are set to be place on the center of the parent (in my > case clicking on a album cover opens a bigger version centered on the window, > or preference windows) We could say that windows are by default placed on the center of the parent. This is a good enough strategy for me. > * I have a custom tooltip implementation: https://i.imgur.com/QE0ZdvM.gif > No idea how to port that. This could be done with subsurfaces. > * I have a slider in a window that pops up next to a button: > https://i.imgur.com/KNotPgA.png > Also no idea. xdg_popups allow positioning their window relative to a parent. If you take a gdk grab when the popup comes up, then it should be handled automatically. > Positioning: I like the current solution that the top most parent defines the > fake root. This makes offset calculations work on both X11 and wayland. > > Window dragging: > > * Dragging the modal dialog could move the parent and dragging the parent could > move the dialog. This should be implemented by a WM. > * Moving preference window should not move the parent and vice versa > > * A popover like widget should move with the parent, but might depending on the > use case be movable independent of the parent. > > So as a result each window could specify if it should move with the parent and > if the parent should move with the window. Basically, this is "should modal dialogs be attached to the window". Currently, we don't have any way of marking a window as a modal dialog.
Filed bug 736145 about modal dialogs under wayland.
the modal dialogs part is fixed for a while now.