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

[Bill Haneman <Bill Haneman Sun COM>]

Havoc Pennington wrote:

> ...
>
> Here's the problem: metacity is full of switch statements that go over
> TYPE_DIALOG, TYPE_NORMAL, TYPE_DOCK, etc. ...
<more points in favor of using a state for this snipped...>

> 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.
>  
OK, so it sounds as though you're undecided about which is best here.
Personally it sounds to me as though the TYPE is the best option.

> 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?
>  
Just to be clear, I'll reiterate my feeling that a WM type called 
TYPE_MAGNIFIER or TYPE_INPUT_DEVICE isn't right.  I think we are looking 
for a WM type or state which allows a behavior needed by a variety of 
applications:

onscreen keyboard (usually opaque, but transparent use cases exist)
magnifier window (always opaque)

some cases for transparency/translucency:
overlays (i.e. things that allow drawing on existing apps, overlay 
highlighting, in-place scanning of interfaces, etc.)
next-generation CTL text input methods?

The "overlay highlighting" and "in place scanning" are use cases of 
interest to accessibility; overlay highlighting would for instance be 
useful to cognitive disabilities, imagine for instance a speech 
interface which speaks when the user is activating UI elements, and 
highlights text as it reads, for instance document contents and 
on-screen labels).  It's possible that such an application may wish to 
_sometimes_ take focus, so perhaps using WM_TAKEFOCUS and leaving the 
focus-or-not decision down to the application is the right thing to do, 
rather than "never focussing "TYPE_OVERLAY" windows.

In-place scanning is similar - imagine using GOK in dwell of scanning 
mode, but instead of requiring GOK to present the UI components to the 
user as separate buttons in the GOK window, allow GOK to highlight the 
currently-selected UI component(s) on screen; to understand this case 
you'd want to have seen GOK demoed in at least dwell and scanning 
modes.  Doing these tasks requires either an alpha-blended overlay 
window, or COMPOSITE plus hacking into the compositing manager;  
TYPE_OVERLAY would make doing this cleaner and easier.

> 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.
>  

See above.

> 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 ;-)
>  
I like OVERLAY.

- Bill

> 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
>
>
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>