On Thu, Sep 12, 2002 at 06:59:31PM -0400, Havoc Pennington wrote:
>
> 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.
Another issue that may crop up is when using Xinerama at 2 differnt
resolutions. The strut on the larger resoution monitor (1) at the
bottom moves off the right hand corner and into no-man's land below
the display of monitor (2). Or does it exist at the bottom of monitor
(2) as well? What are panels excepted to do in this situation? Kicker
currently puts itself in a straight line, thus existing in no-man's
land below the visible space of (2).
I'll try show what i mean with diagrams :)
Monitor (1) and (2) Where panels (and thus the strut)
could go. (Kicker right now) Another option.
+-------+-------+ +-------+-------+ +-------+-------+
| | 2 | | | 2 | | | 2 |
| 1 |_______| | 1 |_______| | 1 |.......|
| | |.......|....... |.......|-------+
+-------+ +-------+ +-------+
Xinerama is a bit of a headache.
> 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?
In the case of openbox/blackbox, the Slit (dock app tray) uses the
strut, but is only as long as the apps it contains. So this strut
weirdness is almost a permanent 'feature'. What we've done is to use
the strut for maximizing and window placement, and ignored it, using
actual windows for snapping. I think that the preferable behavior is
different depending on what the strut is being used for.
I don't know how much change is an option, but it could be changed to
simply be a rectangle. (-1,-1) being the bottom right, like -geometry
works.
Ben
--
I am damn unsatisfied to be killed in this way.
Attachment:
pgpxjhEaGMufU.pgp
Description: PGP signature