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

[Rob Adams <readams readams net>]

It shouldn't be ABOVEALL; the window types should be window types, not
descriptions of semantics.  Maybe TYPE_ACCESSIBILITY or TYPE_KEYBOARD or
something like that.

-Rob 

On Fri, 2004-04-16 at 13:00 +0100, Bill Haneman wrote:
> 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.
> > 
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>