Re: _NET_WORKAREA and dual head
- From: Sasha Vasko <sasha aftercode net>
- To: Bill Haneman <Bill Haneman Sun COM>
- Cc: Lubos Lunak <l lunak suse cz>, wm-spec-list gnome org
- Subject: Re: _NET_WORKAREA and dual head
- Date: Tue, 16 Mar 2004 11:13:52 -0600
Bill Haneman wrote:
Lubos Lunak wrote:
On Tuesday 16 of March 2004 03:38, Billy Biggs wrote:
I agree that our problem is much simpler if we have rectangles fixed
to a screen edge, and that reserving space in the middle of a monitor
does not make sense.
Hmm, ok then.
FWIW I can see some accessibility use cases for reserving
rectangular areas within the screen, in support of
"always on top" sorts of applications like onscreen magnifiers and
virtual keyboards.
However I do appreciate that this complicates matters a good bit
when it comes to implementing support for these sorts of "struts",
Generalized AvoidCover type hint is more difficult then edge-bound
struts, but quite doable. It requires some rules to be defined, such as:
1) Do we need to move other windows out of the way while doing intial
placement of such a window ?
2) what has to be done when such a window changes its size/position ?
3) How to resolve conflict when several such windows claim same spot ?
I could probably draft the set of rules, based on what I found to be
working in real life (I have it implemented and working nicely in
AfterStep 2.0).
and I am not sure how essential such a capability is above and beyond
the existing "reserve edges/corners" behavior.
There are however only four edges to the screen; as more applications
begin to use STRUTS we start to run into problems. For instance,
Absolutely. There most definately will be cases when more generalized
Avoid Cover functionality will bee required. STRUTS as they are at the
moment are rather simplistic and limited solution, and saying that its
good enough is nothing but hiding you head in sand.
GOK's onscreen keyboard currently requires that the user have only one
"panel" for proper operation. ( GOK == Gnome onscreen keyboards for
users who
cannot use a physical keyboard, or in situations such as kiosks where
no physical keyboard is present).
How should we handle the case of a Xinerama screen, on which we choose to
place separate per-"head" panels or other STRUT utilities? This would
require
the more general usage of STRUTS if, for example, one had three tiled
screens
and wished to reserve separate space on the middle physical display.
I guess the upshot is that I think _if_ we can create a more general api
for
reserving screen space, it might be preferable, even if it's more work.
It's not
impossible to think of real use cases for it, and where accessibility is
concerned it
becomes more important to enable these behaviors since the end-user may be
unable to modify window placement manually.
I completely support this.
IMHO both STRUTS and AvoidCover hint have its merits, and both has to be
part of the standard to allow for powerfull and flexible placement policy.
regards,
- Bill
Sasha Vasko.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]