Re: Allowing a11y windows to be on top - bug #136159

[Havoc Pennington <hp redhat com>]

On Fri, 2004-04-16 at 12:22, Bill Haneman wrote:
> 
> Things other than keyboards (for instance magnifiers) and even 
> non-accessibility windows (for instance overlays, transparent windows, 
> etc.) may want to declare this type as well.  The real requirement is 
> for a window type that's _above_ DOCK, therefore ABOVEALL makes the most 
> sense.  I think TYPE_ACCESSIBILITY and TYPE_KEYBOARD are wrong because 
> they actually give imply wrong semantic information (fi applied to 
> magnifiers, or non-accessibility-specific features).

Here's the problem: metacity is full of switch statements that go over
TYPE_DIALOG, TYPE_NORMAL, TYPE_DOCK, etc. If I add a new type, I'll go
through each of these and choose which switch case TYPE_ABOVE_ALL should
get. This choice makes no sense for ABOVE_ALL, because ABOVE_ALL tells
me nothing about the expected behavior (other than stacking).

If ABOVE_ALL is a state then I can define TYPE_NORMAL and
STATE_ABOVE_ALL as behaving exactly like a normal window, only on top of
the dock. And there's no chance a WM author would start changing focus
behavior or something for ABOVE_ALL.

Also, if ABOVE_ALL is a state then it can be changed dynamically.

However, if we could get a real semantic type instead of a state, it
would go a long way to preventing abuse of this hint by media players
and other stuff that should not use it.

I think it would be good to collect the most exhaustive list of apps
that might use ABOVE_ALL that we can and give the real semantic type
hint a good try, I still don't think we've done that. Maybe:
 TYPE_INPUT_DEVICE  (gok, dasher, etc.)
 TYPE_MAGNIFIER
 ... what else have we come up with?

I don't think we can design for transparent windows or overlays without
some more specific functional use-case for what those are and what they
do.
 
Finally, I don't like the name ABOVE_ALL; it invites abuse and confusion
with plain ABOVE. How about OMNIPRESENT or OVERLAY or ... ? someone
think of something good ;-)

In fact is TYPE_OMNIPRESENT the semantic type? Perhaps a window of this
type never gets focus, is sticky, and is above all? Essentially these
windows are conceptually part of the hardware, kept separate from the
desktop.

Havoc