Re: xinerama and struts
- From: Havoc Pennington <hp redhat com>
- To: Mark McLoughlin <mark skynet ie>
- Cc: wm-spec-list gnome org
- Subject: Re: xinerama and struts
- Date: 12 Sep 2002 18:59:31 -0400
Mark McLoughlin <mark skynet ie> writes:
>
> Out of curiosity - is this HEAD or gnome-2-0 or the multihead
> branches ?
gnome-2-0
> 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.
To me allowing the dividing line makes sense. Disallowing it is a punt
solution that makes things easier to implement - which is fine with me
- but I don't see anything _wrong_ with allowing the panel on the
dividing line. It makes sense, if you are using the two monitors as
effectively separate workspaces and only using xinerama rather than
real multihead in order to enable moving windows between monitors.
> 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.
Partial width struts (not bound to Xinerama) cause a lot of
implementation complexity in the window manager because your "work
area" suddenly isn't a rectangle - I'm almost inclined to handle
corner panels by not setting the strut at all, or devising some way to
use the strut only for maximization and ignore it otherwise, or
something... partial struts bound to xinerama are easy because there's
already a per-Xinerama work area to worry about.
Basically with corner panels people seem to be trying to save some
screen real estate vs. a full panel, so they want to be able to move
stuff up next to the corner panel - what is the strut for then? Only
maximization? Does that make any sense - I'm not sure?
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]