Gtk: get usable area of each monitor (excluding panels)

Question

Using gdk_screen_get_monitor_geometry, I can get the total area in pixels and the relative position of each monitor, even when there are two or more used as a single screen.

However, I want to get the usable area (that is, excluding panels) of each monitor. The only thing I have found is _NET_WORKAREA, but that is one giant area stretching across all monitors. Depending on the resolution and arrangement, there may be panels inside this area.

How can I get the actual usable area of each monitor? Ideally, using only Gtk/Gdk, nothing X11-specific.

Torrens

Answer 1

in the end I ended up using xlib directly, various "tricks" like the one suggested above ended up eventually failing in the long run often with odd corner cases and never followed the KISS principle.

The solution I used is in the X-Tile code base.

Torrens

I got x-tile source code, i'm not a dummy. But its easier to see a few system calls compared to searching a full source code dont you think? – Scandalmonger

Sorry about that but your code is a mess and unlike the tagged c language its in python. For others not to waste time, its _NET_WORKAREA, details: standards.freedesktop.org/wm-spec/… – Scandalmonger

Hi @CemKalyoncu and Chris thanks very much espeicaly Cem for pointint it out for newbies like me. – Marchese

Using xlib is not a good approach as Wayland is soon to replace X and you'll have to weed out those calls when you want to port your app to wayland :-/. – Formless

@leo-ufimtsev .... yeah where was Wayland 5 years ago when this question was asked... come to that where is it today... A lot of X app will still be run in a Wayland wrapper for years to come... if anything ever comes of Wayland... – Torrens

yah, I know, annoying :-/. (Le me now working on porting Eclipse from X to Wayland.). Wayland seems legit, lots of folks seem to be porting things over. Gnome/Firefox/Libreoffice to name a few. Wayland has XWayland backward support for X as well, so new Gtk3 apps will probably be pure wayland and older stuff probably won't be ported as much. – Formless

@ChrisCamacho this is supposed to be a place where we help each other. Using "let me google that for you" is rude, and If I were an admin, I will ban you :) – Slav

Answer 2

The following approach is a bit convoluted, but it is what I'd use. It should be robust even when there is complex interaction between the window manager and GTK+ when a window is mapped -- for example, when some of the panels are automatically hidden.

The basic idea is to create a transparent decorationless maximized window for each screen, obtain its geometry (size and position) when it gets mapped (for example, using a map-event callback), and immediately destroy them. That gets you the usable area within each screen. You can then use your existing gdk_screen_get_monitor_geometry() approach to determine how the usable area is split between monitors, if any.

In detail:

Use gdk_display_get_default() to get the default display, then gdk_display_get_n_screens() to find out how many screens it has.

Create a new window for each screen using gtk_window_new(), moving the windows to their respective screens using gtk_window_set_screen(). Undecorate the windows using gtk_window_set_decorated(,FALSE), maximuze them using gtk_window_maximize(,TRUE), and make them transparent using gtk_window_set_opacity(,0.0). Connect the map-event signal to a callback handler (using g_signal_connect()). Show the window using gtk_widget_show().

The signal handler needs to call gtk_window_get_position() and/or gtk_window_get_size() to get the position and/or size of the newly-mapped window, and then destroy the window using gtk_widget_destroy().

Note that in practice, you only need one window. I would personally use a simple loop. I suspect that due to window manager oddities/bugs, it is much more robust to create a new window for each screen, rather than just move the same window between screens. It turns out it is easier, too, as you can use a single simple callback function to obtain the usable area for each screen.

Like I said, this is quite convoluted. On the other hand, a standard application should not care about the screen sizes; it should simply do what the user or window manager asks. Because of that, I would not be surprised if there are no better facilities to find out this information. Screen size may change at any point, for example if the user rotates their display, or changes the display resolution.

Fortress

This is very clever, but I'd like to know whether there might be an approach that works synchronously, i.e. without needing to allow the event loop to cycle. – Diabetes

Keep in mind that not all desktops are composited, so it's possible for opacity-setting to be a no-op. – Parthen

@Zack:If you don't want the event loop of the current application to cycle, fork a child process, and have it return the regions via a pipe as text. – Fortress

@ssokolow: I do believe zero opacity always means the window is not visible, even when composition or transparency is not supported. (In other words, composition provides more gradations, partial transparency, but full transparency or full opacity should always be supported.) I'm too lazy to verify this, though. – Fortress