The Unity panel stays on the top of the "virtual monitor", even when there's no actual monitor covering that portion of the screen

[bp]

Binary package hint: unity-2d

I'm extending my laptop monitor with a native resolution of 1366×768 with an external display with a native resolution of 1280×1024. This situation is poorly handled.

Here's a representation of my setup, which I mirrored in the Monitor configuration:

╔════════╤════════╗
║████████│▒▒▒▒▒▒▒▒║
║░░░░░░░░│▒▒▒▒▒▒▒▒║
╟────────┘▒▒▒▒▒▒▒▒║
║▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒║
║▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒║
║▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒║
║▓▓▓▓▓▓▓▓▓┌───────╢
║▓▓▓▓▓▓▓▓▓│░░░░░░░║
╚═════════╧═══════╝

▓ laptop monitor
▒ external monitor
░ area that is not covered by any monitor
█ placement of the top panel (inside the ░ area)

═ shape of the virtual desktop
─ shape of the area that is actually covered by monitors

I can confirm the panel is placed as pictured because moving the mouse all the way up (where it doesn't belong anyway, see bug #656855) and clicking can open application menus or application indicator menus.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: unity-2d-panel 3.6.1-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.38-6.34-generic 2.6.38-rc7
Uname: Linux 2.6.38-6-generic x86_64
Architecture: amd64
Date: Wed Mar 16 08:03:40 2011
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: unity-2d
UpgradeStatus: Upgraded to natty on 2011-03-11 (4 days ago)

[bp (badpazzword)]

I attach a screenshot.

[Olivier Tilloy (osomon)]

Bug #681101 is an umbrella bug that tracks all the issues related to multi-monitors setups.

[bp (badpazzword)]

Oliver: thank you; I marked myself affected on that and the related, relevant bugs.

[Olivier Tilloy (osomon)]

Fixing the position of the panels (the launcher is also a panel internally) is easy enough: instead of using moveLeft(m_delta) and moveTop(m_delta), the computation of the geometry should add up m_delta to the x/y coordinate, depending on the edge of the panel.

However reserving the struts correctly is slightly more complicated: struts always live at the edge of a screen, so in the case described above, if the panel shows up on the screen on the left, the top strut for it should be screen.y() + panel.height(). But when doing so, the subsequent calculations of the destkop’s available geometry always return a null rectangle, and therefore the other panels (like the launcher) never show up. The computation of the desktop’s available geometry uses _NET_WORKAREA, which on my setup completely excludes the leftmost part of the virtual desktop that contains the first screen.

[Olivier Tilloy (osomon)]

_NET_WORKAREA is not reliable, because what we really are interested in is the available geometry on one given screen, not the rectangle that represents the intersection of the available geometries on all screens. Therefore QDesktopWidget::availableGeometry(…) is of no use to us, and we need to find a more clever way of getting the available geometry on a given screen.

[Olivier Tilloy (osomon)]

There is an (old) interesting discussion at http://mail.gnome.org/archives/wm-spec-list/2004-March/msg00007.html, but unfortunately it doesn’t seem to have led to any useful addition to the EWMH specification.

According to the specification:

« The Window Manager SHOULD calculate this space by taking the current page minus space occupied by dock and panel windows, as indicated by the _NET_WM_STRUT or _NET_WM_STRUT_PARTIAL properties set on client windows. »

We can probably write a similar implementation that will calculate the work area on one given screen, by subtracting from the screen geometry all the strut-reserved areas of all windows on this screen.

[Olivier Tilloy (osomon)]

The solution proposed above works well for the panels (implement at revision 492 of the branch linked).
However, I uncovered another related issue: the launcher’s contextual menus’ geometry is wrong. This is very likely because their calculation internally relies on QDesktopWidget::availableGeometry(…). I’m investigating how to fix that.

[Olivier Tilloy (osomon)]

QMenu’s paintEvent calls a private method (QMenuPrivate::updateActionRects()) that itself calls another private method (QMenuPrivate::popupGeometry()) that relies on QDesktopWidget::availableGeometry(…). The fact that those methods are private makes it rather complicated to override to fix the calculation of the available geometry.

The best solution, that would fix the issue across the whole project, would probably be to re-implement availableGeometry(…) itself by subclassing QDesktopWidget, but then Qt internally retrieves the desktop widget by calling QApplication::desktop(), so we need to override this one too, which I really don’t know how to achieve.

I filed http://bugreports.qt.nokia.com/browse/QTBUG-18380 to track the issue in Qt, thanks bp for the ASCII art which I shamelessly copied to explain the monitors setup there.

[Olivier Tilloy (osomon)]

I attached a patch to http://bugreports.qt.nokia.com/browse/QTBUG-18380 that fixes the issue. Together with the branch linked to this bug report, it fully fixes the issue of the panel not being correctly positioned.

[Colin Law (colin-law)]

I am not sure how the system works, are we likely to see the fix applied soon? It is a real pain not being able to align my monitors optimally. It would be great to see it fixed.

[Olivier Tilloy (osomon)]

@Colin: I couldn’t agree more, but I can’t comment on whether the patch will be applied any time soon; I first need to get an upstream Qt developer to review it. Note that the patch potentially has an impact on every single Qt application out there, so it will have to go through a very careful review and testing phase.

[Colin Law (colin-law)]

@Olivier: Understood. Many thanks.

[Gerry Boland (gerboland)]

Proper multi-monitor support was added to unity-2d in version 5.8, this bug has been fixed.