(oneirc) default placement of windows is behind panel

More info - this happens for all apps, not just gnome-terminal and may be related to bug 845856, since I also get the invisible menu when this happens.

Just to confirm your screenshot, you are using a multimonitor
configuration which places one monitor on top and one monitor below?

If this is the case, this situation needs some more testing and we'll
likely fix all the bugs that we can find in this particular case when
it is appropriate to do so, as this isn't a common usecase that DX has
encountered (indeed, this workflow is also broken with gnome-panel and
ubuntu-classic as gnome-panel does not account for the case were
"strut" windows are placed in the middle of the screen

On Fri, Sep 23, 2011 at 5:26 PM, Jane Silber <email address hidden> wrote:
> Public bug reported:
>
> In an Oneric beta, running on a laptop with an external monitor, windows
> that open on the laptop screen by default open with the top window
> decoration behind the top panel. This makes it very difficult to move
> those windows. See attached screenshot. The bar in the middle is the
> division between the two screens.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 11.10
> Package: unity 4.16.0-0ubuntu2
> ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
> Uname: Linux 3.0.0-11-generic x86_64
> .tmp.unity.support.test.0:
>
> ApportVersion: 1.23-0ubuntu1
> Architecture: amd64
> CompizPlugins: [core,bailer,detection,composite,opengl,compiztoolbox,decor,resize,vpswitch,mousepoll,grid,snap,imgpng,place,session,move,regex,gnomecompat,unitymtgrabhandles,wall,animation,workarounds,expo,fade,ezoom,scale,unityshell]
> CompositorRunning: compiz
> Date: Fri Sep 23 10:21:45 2011
> DistUpgraded: Log time: 2011-09-07 16:36:15.956610
> DistroCodename: oneiric
> DistroVariant: ubuntu
> GraphicsCard:
>  Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller])
>   Subsystem: Lenovo Device [17aa:215a]
> InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
> MachineType: LENOVO 5129CTO
> ProcEnviron:
>  PATH=(custom, no user)
>  LANG=en_GB.UTF-8
>  SHELL=/bin/bash
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-11-generic root=UUID=52f3f8dd-ab0d-4f3b-8cef-9bc54492e659 ro quiet splash vt.handoff=7
> SourcePackage: unity
> UpgradeStatus: Upgraded to oneiric on 2011-09-07 (15 days ago)
> dmi.bios.date: 09/15/2010
> dmi.bios.vendor: LENOVO
> dmi.bios.version: 6QET53WW (1.23 )
> dmi.board.name: 5129CTO
> dmi.board.vendor: LENOVO
> dmi.board.version: Not Available
> dmi.chassis.asset.tag: No Asset Information
> dmi.chassis.type: 10
> dmi.chassis.vendor: LENOVO
> dmi.chassis.version: Not Available
> dmi.modalias: dmi:bvnLENOVO:bvr6QET53WW(1.23):bd09/15/2010:svnLENOVO:pn5129CTO:pvrThinkPadX201s:rvnLENOVO:rn5129CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
> dmi.product.name: 5129CTO
> dmi.product.version: ThinkPad X201s
> dmi.sys.vendor: LENOVO
> version.compiz: compiz 1:0.9.5.94+bzr2803-0ubuntu5
> version.ia32-libs: ia32-libs 20090808ubuntu22
> version.libdrm2: libdrm2 2.4.26-1ubuntu1
> version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu3
> version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
> version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu3
> version.xserver-xorg: xserver-xorg 1:7.6+7ubuntu7
> version.xserver-xorg-inp...

OK, a quick note on this bug so that we know what's going on.

Basically, this case isn't covered by any window management interoperability standards (both ICCCM and EWMH/NETWM), both _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL make the assumption that your panels will always be on the edge of the *screen* and not of a particular monitor within that screen. That being said, there are a number of panels and docks and Unity even, which support the case of panels being positioned in the middle of the screen. However, as I've observed with all of these cases, this behaviour is totally broken with pretty much every window manager out there because neither strut hint can be set correctly without completely breaking maximization on one monitor.

As such, there's two things we can do. I think that we should do both, one is a long term solution and one is short term

1) The short term solution is that the unity plugin is able to override window placement in certain cases, and we can just change this override to ensure that windows never overlap panels in the case that their struts cannot be set correctly.
2) The long term solution is to propose a _NET_WM_STRUT_REGION property on the root window to freedesktop to cover this case and implement support for that inside of compiz (ideally, this should really deprecate both _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL as both are fundamentally broken and too limited).

Yes, I have things set up with the external monitor above the laptop screen.

WRT your comment that this is a use case the DX team hasn't encountered, do you mean external monitors in general or the positioning of one on top of the other? The reason I have it positioned this way is mainly because of the inability to tell Unity which screen I want the launcher on. Because it is locked (AFAICT) to the laptop screen, it creates longer mouse distances to travel to the launcher/dash when I position the external monitor to the side of the laptop one. If you fix it so that I can move the launcher to the other screen (which I think should be the design any way), then I'll position them differently!

On Sun, Sep 25, 2011 at 9:06 PM, Jane Silber <email address hidden> wrote:
> Yes, I have things set up with the external monitor above the laptop
> screen.
>
> WRT your comment that this is a use case the DX team hasn't encountered,
> do you mean external monitors in general or the positioning of one on
> top of the other?

I'm referring to the case of one monitor on top of another. Most of us
have multimonitor setups, but the ones I've encountered by far are the
left-to-right kind.

I don't think it's so much that DX hasn't encountered the
top-bottom-with-bottom-primary usecase, its more a case that this is
not a common usecase and as such the multimonitor support hasn't been
optimized for this arrangement yet. (As I mentioned earlier, the
freedesktop.org standards make this case ... difficult to support,
where you have the primary monitors containing panels and monitors
which are adjacent to the position of those panels, and as such, I
haven't seen any desktop environment get this right).

That's not to say that it's not a valid usecase, in my opinion it is
totally valid and we should support it (in our current architecture
that's more or less trivial because Unity has a high level of control
over what the window manager (compiz) is doing in this case anyways).

I do think, however, that I need to write up an amendment to the
standard for the position of windows relative to panels that was set
by freedesktop in the extended window manager hints, because it
clearly doesn't take into account this use-case (I would imagine that
I am not the first person to bring this up either).

> The reason I have it positioned this way is mainly
> because of the inability to tell Unity which screen I want the launcher
> on.
> Because it is locked (AFAICT) to the laptop screen, it creates
> longer mouse distances to travel to the launcher/dash when I position
> the external monitor to the side of the laptop one.

I don't work on the launcher or the dash, but at least in my testing
just now with xrandr, they chose the monitor which is marked
"primary". Unfortunately, pretty much every driver stack has a
different way of doing this which makes supporting it a bit of a
nightmare, but if you know what hardware / driver combination you're
on, then I know at least two ways of doing this off-hand:

For intel / radeon / nouveau (eg, open source drivers) : At least in
the graphical monitor's configuration tool provided by
gnome-control-center there isn't an option to mark one monitor or the
other primary (I assume at least by playing with it that it picks the
one you configured to be on the left-most side to be primary, and the
bottom-most to be primary as well). But you can get a list output of
all of your monitors with `xrandr` and then do something like

xrandr --output (monitor-id) --primary

And the launcher will move to the monitor you specify.

For the binary nvidia blob, the setting is in the NVIDIA X Server
Settings tool, as "mark this display as primary" when setting up
monitors. It's been a long time since I last used that driver though
(I use nouveau), so I am unsure as to whether or not this option is
still broken or exactly what this was called.

F...

Well, the issue with the launcher is because there is no design for what happens if you want to put your launcher on a monitor that is not left-most. Main issue being, how would you invoke it? The good news is Design are working on multi-monitor support as a priority for 12.04. The bad news is that it's still going to take a bit of time for that to trickle through to something testable.

This bug, however, is completely valid on it's own and Sam is working out how to workaround the limitations of the spec so we can have something working for 11.10.

This bug was fixed in the package unity - 4.20.0-0ubuntu1

---------------
unity (4.20.0-0ubuntu1) oneiric; urgency=low

  * New upstream release + cherry-pick:
    - compiz crashed with SIGSEGV in PluginClassHandler<UnityWindow,
      CompWindow, 0>::get() (LP: #835259)
    - dash does not scroll down during keyboard navigation (LP: #852506)
    - compiz crashed with SIGSEGV in _XFreeEventCookies() (LP: #851472)
    - compiz crashed with SIGSEGV in g_object_unref() (LP: #847512)
    - compiz crashed with SIGSEGV in nux::WindowCompositor::MouseEventCycle()
      (LP: #831678)
    - compiz and X can disagree on the stacking order (LP: #845719)
    - compiz crashed with SIGSEGV in unity::dash::LensView::OnResultAdded()
      (LP: #855252)
    - CCSM crashes Unity (LP: #861643)
    - compiz crashed with SIGSEGV in PrivateWindow::addWindowStackChanges()
      (LP: #862115)
    - Touch - When dragging a window with a 3 touch, dragging to the top
      should show the maximize gesture preview. (LP: #750316)
    - compiz crashed with SIGABRT in raise() (LP: #750386)
    - Launcher - Spread should not affect the state of window (LP: #764673)
    - [UIFe] Add system setting icon to Launcher (LP: #764744)
    - compiz crashed with SIGABRT in raise() [Merely unchecking the Unity
      plugin is enough to crash Compiz...] (LP: #823386)
    - Launcher - does not hide if revealed from top 24px of the left edge of
      the screen (LP: #835989)
    - Clickable areas of previously active window remains on 'Show Desktop'
      (LP: #836325)
    - Cannot search for some apps in Dash (LP: #837075)
    - Dash - Search box cursor not responding correctly to focus (LP: #839704)
    - Multi-display: Application menu only showing on primary screen
      (LP: #845212)
    - Ellipsized values in size filter (LP: #851359)
    - (oneiric) dash result expansions don't display icons (LP: #854615)
    - run the wrong command if enter is hit before the view is refreshed
      (LP: #856205)
    - Java application windows cut-off/truncated/not displayed properly
      (LP: #857201)
    - compiz crashed with SIGSEGV in sigc::signal_base::impl() (LP: #831769)
    - Minimizing a window should switch focus to the windows underneath it
      (breaks restore) (LP: #859885)
    - Ratings filter allows ratings > 1.0 (LP: #861255)
    - Serious Unity problem stuck in spread when dragging icons back to the
      dash (LP: #862045)
    - Must use hardware keyboard to perform search for applications in Unity
      (LP: #739812)
    - Files lens should also search Downloads (LP: #748915)
    - The dash crosses the monitor boundary when resolution is 1152x864 or
      lesser width (LP: #765338)
    - Dash - dragging a file outside of the Desktop Dash should close the Dash
      (LP: #764641)
    - Text in Dash search text box overflows and doesn't crop with longer
      strings; RtL input starts in wrong place (LP: #834765)
    - Where the average background colour is either very light or dark, adjust
      this value to darken/lighten in order to preserve readability
      (LP: #837993)
    - Dash does not resize when I connect to an external display and mirror
      displays (LP: #83813...