Re: xinerama and struts

[Mark McLoughlin <mark skynet ie>]

Hi Havoc,

On 12 Sep 2002, Havoc Pennington wrote:

> Hi,
>
> We probably shouldn't put this in 1.2, as I haven't tried implementing
> it yet, but I just configured a xinerama setup and am feeling the
> _NET_WM_STRUT-not-working pain. (What does KWin do here?)

	Out of curiosity - is this HEAD or gnome-2-0 or the multihead
branches ?

> First the user-visible behavior I'm after: gnome panel can be on any
> of the four sides of any xinerama screen. So if I have two xinerama
> screens side by side, the panels are allowed to be on either side of
> the dividing line between the monitors. There are 8 total panel
> positions.

	This is actually a bug. The panel shouldn't be allowed on the
dividing line - its logged in bugzilla. There should only be 6 allowed
panel positions in that case.

> Window manager panel handling in various cases:
>  - when maximizing, it should be to one monitor, avoiding the 4 panels
>    on that monitor
>  - desktop icons should avoid all panels, but for the panels
>    in between the two monitors, struts aren't really sufficient;
>    icons should be allowed on both monitors, but not underneath
>    the panels in the center.
>  - for placing windows, you don't want to place overlapping any
>    panels
>
> Here is a proposed solution that probably allows all of the above:
>
>  _NET_WM_STRUT_XINERAMA
>
>  Like _NET_WM_STRUT but has a 5th integer in the array, for the index
>  of the Xinerama monitor the strut applies to. The strut only applies
>  to that Xinerama monitor. The strut should be taken with respect to
>  the geometry of the Xinerama monitor.
>
> However, gnome-panel would probably use _NET_WM_STRUT_XINERAMA
> exclusively, and never _NET_WM_STRUT. And anything you can do
> with _NET_WM_STRUT can be done with _NET_WM_STRUT_XINERAMA.
>
> Perhaps we should just say that _NET_WM_STRUT has an optional 5th
> field, and if present it confines that strut to a single Xinerama and
> makes it relative to the given Xinerama. Would this count as an
> incompatible change?

	Because the "panel on the dividing" line is a non issue, at
least for GNOME, the issue is essentially the same as having a panel
that does not occupy a full strut - e.g. a floating panel - I'd much
prefer some sort of a partial width strut solution to the one above.

	Maybe this could be a _NET_WM_STRUT_GEOMETRY property which
also species the struts offset and length as well as the struts width.
It could be required for panels to set both properties so a WM
implementation could chose to ignore the geometry property if it
wishes. How does that sound ?

Cheers,
Mark.