[Gambas-user] Test Screen.Available values

[Benoit Minisini]

Le 16/05/2023 à 12:00, Bruce Steers a écrit :
> Hi all.
> 
> I have a problem with a program that Benoit does not get the same bug 
> and wondered if some people could test this program.
> 
> the program is a simple screenshot program.
> I made it because I now use a laptop with 2 screens attached and with 
> the built-in screenshot programs it grabs the entire area of both 
> screens and i then have to crop the picture.
> 
> This application detects what screen the mouse is on via an addition to 
> Mouse.class (Mouse.Screen) and only grabs that screens area.
> 
> It also has an option to "hide panels" , if this is selected then is 
> uses the Screen.Available co'ords not the normal co'ords.
> like so...
> 
>    Dim s As Screen = Screens[Mouse.Screen]
> 
>    If NoPanels Then
>      hPic = Desktop.Screenshot(s.AvailableX, s.AvailableY, 
> s.AvailableWidth, s.AvailableHeight)
>    Else
>      hPic = Desktop.Screenshot(s.x, s.y, s.w, s.h)
>    Endif
> 
> 
> The problem....
> On my system this works as expected with GTK3 , if NoPanels is selected 
> the screenshot only includes the internal usable screen and not the 
> outer desktop panels.
> 
> (note: my config is the plug-in 1280x1024 monitor is default screen, 
> laptop built-in 1366x768 is secondary screen)
> 
 > [...]

For information: both QT and GTK components use the API provided by the 
toolkit to get the screen available dimensions.

So if it does not work, it should not be Gambas' fault.

The toolkit API is supposed to adapt to the underlying windowing system 
(X or Wayland) to get that information.

On X11, that information is provided by X11 properties attached to the 
root window by the window manager. These properties are computed by 
taking the screen size and removing the dimensions of top-level windows 
indicating (with other X11 properties) that they are desktop "panels".

Here is a comment from the QT source code :

----8<-----------------------------------------------------------

Using _NET_WORKAREA to calculate the available desktop geometry on 
multi-head systems (systems with more than one monitor) is unreliable. 
Different WMs have different interpretations of what _NET_WORKAREA means 
with multiple attached monitors. This gets worse when monitors have 
different dimensions and/or screens are not virtually aligned. In Qt we 
want the available geometry per monitor (QScreen), not desktop 
(represented by _NET_WORKAREA). WM specification does not have an atom 
for this. Thus, QScreen is limted by the lack of support from the 
underlying system.

One option could be that Qt does WM's job of calculating this by 
subtracting geometries of _NET_WM_STRUT_PARTIAL and windows where 
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK.

But this won't work on Gnome 3 shell as it seems that on this desktop 
environment the tool panel is painted directly on the root window. Maybe 
there is some Gnome/GTK API that could be used to get height of the 
panel, but I did not find one. Maybe other WMs have their own tricks, so 
the reliability of this approach is questionable.

----8<-----------------------------------------------------------

As for Wayland, no idea. I guess you can't have this information outside 
of a specific API implemented in your specific compositor. :-(

Regards,

-- 
Benoît Minisini.