GNOME Bugzilla – Bug 746723
testxinerama fails under wayland
Last modified: 2018-04-14 23:56:42 UTC
I was playing with the gtk+ wayland mode handling and tried to use testxinerama under wayland, and it fails badly. one arguable bug in gtk+, but more likely lots in the test: the test calls gdk_screen_get_monitor_geometry before we've processed all the wayland events to configure outputs. The tests relies on this to move the windows to each monitor, and any monitor reconfiguration later fails if this fails. This leads to the test getting 0x0@0,0 for all the monitors. When monitor reconfiguration happens (when wayland events get processed), because all three windows are on the same screen from the first bug, it uses gdk_screen_get_monitor_at_window and updates all 3 monitors with the same info.
Created attachment 300248 [details] [review] first attempt at a patch This shows the problem a bit more clearly, seems to be at least useable here even if the windows never end up on the correct monitors.
The gtk_window_move() function which I assume tries to put the window on the global position (x, y) will not be implementable on Wayland as clients cannot position them self globally. A client can fullscreen to a specified output, but would it then unfullscreen, the compositor may choose whatever position it wants which usually would be where it happened to be before fullscreening. Whats the usual reasons for needing to do gtk_window_move() (including to certain outputs), and are there maybe other ways we can expose such functionality?
(In reply to Jonas Ådahl from comment #2) > Whats the usual reasons for needing to do gtk_window_move() (including to > certain outputs), and are there maybe other ways we can expose such > functionality? Use cases that could be relevant: - A special purpose application that needs to control on which outputs its windows go (think trading desk, 3 monitors...). Sounds like 'special compositor' to me - Click on a link in application A to open a document in another application - may want to keep the new window on the same monitor ? - Implement a 'open window on other monitor' function inside an app (I think we're just debating adding 'move to other monitor' in the shell window menu elsewhere).
(In reply to Matthias Clasen from comment #3) > (In reply to Jonas Ådahl from comment #2) > > > Whats the usual reasons for needing to do gtk_window_move() (including to > > certain outputs), and are there maybe other ways we can expose such > > functionality? > > Use cases that could be relevant: > > - A special purpose application that needs to control on which outputs its > windows go (think trading desk, 3 monitors...). Sounds like 'special > compositor' to me Sounds a bit specialized yes, but I wonder if some kind of "remember my position" and "restore my position" protocol could kind of solve that. It has been discussed before, but no one has come up with a good solution to how to do it so far AFIAK. > > - Click on a link in application A to open a document in another application > - may want to keep the new window on the same monitor ? There has been ideas floating around about a startup notification / controlled positioning kind of protocol that could solve this. > > - Implement a 'open window on other monitor' function inside an app (I think > we're just debating adding 'move to other monitor' in the shell window menu > elsewhere). What would the point of opening the window on some other monitor being?
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