GNOME Bugzilla – Bug 755699
GdkX11Screen: Please fix gdk_screen_get_monitor_workarea
Last modified: 2015-10-26 03:26:31 UTC
Currently gdk_screen_get_monitor_workarea only returns correct values for the primary monitor, and for all other monitors it returns the monitor_geometry instead. First of all this is not documented, so its not clear at all. Second, I feel this is an artificial constraint that makes things unnecessary complicated. Can you please fix the functions so that it correctly returns the workarea geometry for all monitors? I also do not understand what L-Shaped monitors are supposed to be? Sure a screen comprised of several monitors can be L-Shaped, but how can a single monitor have an L-shape? In any case, please fix this function so that it at least returns the correct monitor geometry for any non L-shape monitor, no matter if the monitor is the primary monitor or a secondary monitor. Why do I need this: When I resize a GtkWindow to be bigger than the real workarea I get problems with moving and resizing it, the window somehow behaves like it is fullscreen even though it is not.
P.S: Here is an example. I have a Monitor of size 2560x1440 and a panel of height 40px, so the height of my window should not exceed 1400 pixels unless its fullscreen. Now I create a GtkWindow without window decorations and set its height and width to something between 0 and the height or width reported by gdk_screen_get_monitor_workarea. If I set the height to 1440 pixels instead of 1400, then I can no longer resize or move the window programatically until I move it explicitly to some other monitor. When I resize the window pixel by pixel, I can see when it reaches 1400 it suddenly stops growing until I set the height to exactly 1440, then it just resizes to this height and the above problems start.
The current behavior of the function is a result of limitations of the underlying protocol. It only allows a single rectangle to be specified (well, one per workspace, but that doesn't help for multiple monitors). It can't be fixed without changing the window manager spec.
Hello Matthias, thanks for you reply. I have come to the same conclusion in the meantime. But it would still be nice to have a better solution or workaround then we have now. And I wonder if there is an alternative way of computing this information. At least GTK+ seems to know the required information when I resize the window, since resizing is suspended when the bottom edge of my GtkWindow reaches the upper edge of my bottom panel, as I wrote above when I resize the window pixel by pixel and I reach 1400 px then the window stops growing until it reaches 1439 pixels, and then when I set 1440 px it suddenly turns to be fullscreen (and cover the panel). The same applies to moving the window, I cannot move the window over/under the panel, no matter on which monitor I try. So there must be some state inside Gtk+ that deals with that, or am I wrong? In the mean time, until a better solution can be found (if its even possible), could you add a notice to the documentation explaining this behavior?
> It can't be fixed without changing the window manager spec. Right now the implementation uses _NET_WORKAREA, how about using _NET_WM_STRUT_PARTIAL [1] instead? That looks like it would support our requirement. To keep compatibility we can use _NET_WORKAREA for the primary monitor and fallback to _NET_WM_STRUT[_PARTIAL] for all other monitors, would that work? Another solution might be to add a new GTK+ function such as ** GdkRectangle **gtk_screen_get_monitor_struts (GdkScreen *screen, gint monitor) ** That returns a list of GdkRectangles (one for each strut on the monitor) If all cannot fix it, then would it be possible not to change the spec but to extend the spec and add another hint that is able to store per monitor work area information? Like a "_NET_WORKAREA_PER_MONITOR" hint? GTK+ could check if the window manager supports this and fall back to the current implementation if not. [1]: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#NETWMSTRUTPARTIAL
Using struts is not a practical solution, since they are on random other clients' windows, not on the root window. You don't want every GTK+ application to monitor all other toplevels to see if they put up a strut. The window manager is the one who is supposed to collect all the struts and convert them to the workarea property that clients can read off the root window. Unfortunately, it is not flexible enough to make this work perfectly in a mult-monitor world. I personally don't think workarea is important enough to spend tons of time on this.