For several reasons I need to get the number of monitors connected to the system, its physical resolution, the scale, and the work area available.
I found that gdk_display_get_n_monitors() returns the first value, and with that I have access to the GdkMonitor object, which returns all the other information. All this seems to work both under X11 and Wayland, with the exception of the working area, which is only returned correctly under X11.
So my questions are:
is there a way of getting the right working area under Wayland?
are all these calls “future proof” for Wayland? (I mean: is this really allowed under Wayland, and not something that works today but in a future will/could be removed?)
And, of course, the same for the signals that notify that a monitor has been added/removed, or the resolution has changed.
I created an extension for Gnome Shell that restores the desktop icons (it is based on the original Desktop Icons from Carlos Soriano, but moving as many logic as possible into an external GTK program). Currently I’m passing this information from a little extension to the program, but since I’m going to move that part into the program itself for the X11 path (and thus allow to use it in stand-alone mode if desired under X11), I wanted to know if it could work in the Wayland path too.
Just curious: if you remove getting the number of monitors in Wayland, how can a program like Impress know if it can use a double-screen configuration? (like when putting a presentation in screen 0, and the current and next slide and the notes of the presentation in screen 1).
You will need some GNOME Shell specific code, then, because GDK does not have that kind of information available on all platforms. Luckily, since it’s a shell extension, you can poke at the compositor’s internals.
I didn’t say that at all. I said we’re going to remove X11-isms from the monitor API in GDK, like the work area, or whether the monitor is “primary”. There is no Wayland (or Windows, or macOS) equivalent for those concepts.
In general, they should be using platform-specific API, and not rely on GDK being a leaky abstraction.
The “0” monitor might not be the internal panel of a laptop; nor the “1” monitor might be the “presentation”; applications will need to have UI to select the output depending on user input, or we’re going to need protocol extensions for marking monitors for a specific/preferred usage in the system settings, and reflect those settings in applications. Those protocol extensions—both in X11 and Wayland— do not exist at the moment.