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

[Bill Haneman <Bill Haneman Sun COM>]

Lubos Lunak wrote:
> On Thursday 15 of April 2004 22:24, Brian Cameron wrote:
>
> > This email is in regards to bugzilla bug 136159, "metacity allows some
> > non-child dialogs to obscure WM_DOCK windows".  See:
> >
> >   http://bugzilla.gnome.org/show_bug.cgi?id=136159
> >
> > The need to have a11y windows, such as GOK, appear above all other windows
> > has been highlighted on the wm-spec list before.  Here is a brief summary
> > of the discussions so far on this topic:
>
>
>
> > + Here is where Lubos asked for a proof of concept:
> >
> >     http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00048.html
> >
> > + And Havoc agreed a proof of concept was in order:
> >
> >     http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00056.html
> >
> > So, isn't it only necessary to create a proof-of-concept in order to move
> > forward on making this feature a part of the desktop?
>
>
>  To make this clear, I didn't ask for a proof-of-concept for the actual hint 
> (I agree with Havoc that it's better to have a window type for these 
> accessibility windows rather than 
> _NET_WM_WINDOW_STATE_REALLY_ABOVE_ALL_AND_I_MEAN_IT). I have no problem with 
> adding this to the spec or adjusting KWin.

I too think that a separate window type would be better.  Are there any 
objections to adding _NET_WM_TYPE_ABOVEALL and implementing support in 
metacity?

I agree that the xsscreensaver issue is a bit harder; I think that the 
most workable solution in the near-term is to have the WM handle screen 
locking, at least once the unlock dialog is posted.  Possibly some 
negotiation between the WM and the screen lock agent would be required 
in order to preserve some level of assurance that misbehaved apps won't 
post content inappropriately during the unlock process.

- Bill


>  What I didn't like was the idea of the WM handling the windows while the 
> screen is locked 
> (http://mail.gnome.org/archives/wm-spec-list/2003-September/msg00012.html), 
> and I asked for a proof-of-concept implementation of that, as I still don't 
> believe screen locking using the WM will work well. On the other hand, if the 
> locking remains the way it is, then somehow the locking application needs to 
> temporarily start handling the accessibility windows itself while the screen 
> is locked - not very nice either.