diff options
author | Gatis Paeglis <gatis.paeglis@qt.io> | 2017-07-21 14:01:56 +0200 |
---|---|---|
committer | Frederik Gladhorn <frederik.gladhorn@qt.io> | 2017-08-02 23:15:32 +0000 |
commit | 5a1f1345aad720449f0417304aeb35cdeb3e00c2 (patch) | |
tree | 942e842ed37da680c023c51fca7b01ff09274717 /src/widgets/kernel | |
parent | 6c2bfbf88efa745882c636d9b91c4210b8fa5572 (diff) |
xcb: don't rely on _NET_WORKAREA for available geometry on multi-head systems
On X11, QScreen::availableGeometry() is broken with multi-head systems,
and there doesn't seem to be a real fix for this due to limitation in
the protocol and therefore support in WMs (more details in the
patch). In Gnome this issue is more visible because on this DE the
_NET_WORKAREA rectangle represents the intersection of the available
geometries on all monitors. This results in a big area of "dead space"
on the secondary screen, when primary screen is positioned lower in the
virtual space. If menu is opened by clicking in this dead space, the menu
is awfully misplaced (qmenu uses availableGeometry() to calculate the
position of menu).
On Ubuntu with Unity (same is true for KDE Neon+Kwin and LUbuntu+Openbox),
_NET_WORKAREA returns a bounding rectangle containing all monitors.
Which does not cause the menu misplacement as "dead space" is outside
clickable area. But this does not mean that the QScreen::availableGeometry()
reported values are correct. With the same setup as described above,
QScreen::availableGeometry() thinks that we have a tool panel on the
right screen, when in reality it is on the left screen.
AwesomeWM for example does not set _NET_WORKAREA at all, which means
QScreen::availableGeometry() == QScreen::geometry(). I am not aware that it
would cause any issues for popup/menu window positioning in Qt (Qt positions
these windows manually by bypassing WM (via Qt::BypassWindowManagerHint) and
using availableGeometry for calculations. With this patch, we would take the
same code path as if _NET_WORKAREA was not set (where we know that_NET_WORKAREA
is cleary wrong). The solution here is to recognize _NET_WORKAREA as true
available geometry only in specific cases (cases where the meaning is cleary
defined by the specification) and adjust the documentation accordingly.
Not knowing the true available geometry on X11 is mitigated by WMs. Window
manager can position windows as it wants. WMs are smart enough not to place
windows on top of reserved areas at edges (even if user has explicitly requested
this via setGeometry based on inaccurate information from availableGeometry()).
[ChangeLog][Platform Specific Changes][Linux] The _NET_WORKAREA atom is
used for calculating QScreen::availableGeometry() only on systems with one
monitor. In all other cases QScreen::availableGeometry() is equal to
QScreen::geometry(). To restore the legacy behavior with untrustworthy
values in QScreen::availableGeometry() set QT_RELY_ON_NET_WORKAREA_ATOM=1
environment variable.
Task-number: QTBUG-60513
Task-number: QTBUG-29278
Task-number: QTBUG-43768
Task-number: QTBUG-18380
Change-Id: I7e0f62f81d1444991b8a6c007c2527d8f96088c2
Reviewed-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Diffstat (limited to 'src/widgets/kernel')
-rw-r--r-- | src/widgets/kernel/qdesktopwidget.qdoc | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/widgets/kernel/qdesktopwidget.qdoc b/src/widgets/kernel/qdesktopwidget.qdoc index 27d05ece8c..fdf6a27597 100644 --- a/src/widgets/kernel/qdesktopwidget.qdoc +++ b/src/widgets/kernel/qdesktopwidget.qdoc @@ -152,7 +152,7 @@ on \macos, or the task bar on Windows). The default screen is used if \a screen is -1. - \sa screenNumber(), screenGeometry() + \sa screenNumber(), screenGeometry(), QScreen::availableGeometry() */ /*! |