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

[Bill Haneman <Bill Haneman Sun COM>]

Rob Adams wrote:
> 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.

Hi Rob:

Thanks for your input.  I do disagree with your naming assessment 
though... types like "DOCK" already are semantic.

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

- Bill

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