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

[David Bolter <david bolter utoronto ca>]

Havoc Pennington wrote:
> 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.

If we step back from the code and think of state, wouldn't we  all agree 
that being topmost, or above all, or omnipresent, or unoccluded is a 
state, and that state can shift to other windows... ?  I'm thinking in 
the passive (get_state kind of) sense, but it also applies to the active 
(set_state kind of) sense too.

I think a TYPE should say something different -- including describing 
what states can/can't be given and can/can't be taken away.

(I could be way off, I have even glimpsed the WM source.)

> 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, I agree with the "part of the hardware" line of thinking.  It is 
almost like killing part of the desktop space creating a dead space that 
only the owner can use...

[aside: Ideally, things like gok get their own dedicated space, and the 
rest of the GUI gets squeezed into the remainder.  This isn't the case 
we are discussing though.]

OMNIPRESENT is close.  To use a desktop metaphor, I suppose 
TYPE_PAPERWEIGHT might be cute... but not clear.

I think your app list idea will be helpful, I'd like to attempt to 
decribe perhaps whay kind of apps should get priority...

starting from the top:

----------
gui that must be seen, but does not occlude.
translucent/transparent windows, mouse pointers, fleeting indicators 
(mouse pointer finders), visual sound alerts (with no ok button),...
----------
*gui that must always be seen, but occludes other gui. (e.g. gok, 
magnifier, dasher) -- a translucent gok would be nice ;-)
----------
regular apps
----------
bottom dwellers
desktop icons etc.
----------

*I think this is a special case.  If the user wants two of these kinds 
of things, then ideally the user can specify which gets priority.

I'm getting called away :-(  -- all for now.

HTH,

David

> Havoc
>
>
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list