[Gambas-user] Test Screen.Available values

[Bruce Steers]

On Tue, 16 May 2023 at 13:35, Benoit Minisini <
benoit.minisini at gambas-basic.org> wrote:

> 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.
>

Thank you Bruce, Benoit, Mayost
So i guess with all that the best way to add / use a feature like this
would be to just add a disclaimer that it may or may not work depending on
the system.

Respects
BruceS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20230516/8deb641e/attachment.htm>