Re: Re: Re: _NET_WM_STATE_ABOVE and _NET_WM_STATE_FULLSCREEN

On Sunday 29 May 2011 21:27:18 Sam Spilsbury wrote:
> On Sun, May 29, 2011 at 7:56 PM, Martin Gräßlin <[email protected]> wrote:
> > On Sunday 29 May 2011 19:26:05 you wrote:
> >> On Sun, May 29, 2011 at 7:13 PM, Martin Gräßlin <[email protected]> wrote:
> >> > On Sunday 29 May 2011 18:42:28 Sam Spilsbury wrote:
> >> >> Hi Everyone,
> >> >>
> >> >> Someone just sent me an email, and I followed that by filing a bug[0]
> >> >> asking about stacking order, namely how to get always-on-top windows
> >> >> to stack above fullscreen ones for the eg, on-screen-keyboard case. It
> >> >> seems like in the EWMH that this case is not handled, since it asks
> >> >> for fullscreen windows to be above _NET_WM_TYPE_DOCK and
> >> >> _NET_WM_STATE_ABOVE windows [1]. This doesn't make much sense to me,
> >> >> and I'm wondering what the correct implementation here is.
> >> > There is somewhere a note that fullscreen windows are on top of everything else in
> > case they
> >> > are focused and are restacked below above and dock windows if not focused. This 
is
> > also
> >> > how kwin handles it. E.g. you can raise Yakuake (using above) over a fullscreen 
window
> > as it
> >> > will get focus immediately. The dock is also put on top of the fullscreen window in that
> > case.
> >> >
> >>
> >> Yeah, this is how compiz handles it (at least for the docks). I guess
> >> my question is more pertinent to the case of what we do with above
> >> windows which are not in focus along with fullscreen windows - do we
> >> stack them below the on-focus fullscreen window (breaks the on-screen
> >> keyboard case) or do we stack them above?
> > My understand is that such windows should be stacked below the fullscreen windows. 
The
> > on-sceen keyboard is a use-case not yet in existance when the EWMH was written and
> > looks to me like we need a new flag for those.
> >
> > Cheers
> > Martin
> 
> I had a more in-depth look at this case just now and thought of a
> better idea. In the case of on-screen keyboards, it would seem like a
> better idea for them to communicate with the relevant accessibility
> interface (eg AT-SPI) in order for them to make themselves a
> _NET_WM_WINDOW_TYPE_UTILITY and set their WM_TRANSIENT_FOR to the
> active window which supports input by them.
Yes that sounds like a very good solution as it does not require any changes in existing 
window managers and is what you would expect.

Cheers
Martin

_______________________________________________
wm-spec-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/wm-spec-list

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk3iUJQACgkQqVXwidMiVroz2QCfR9dRHmOSPUa2u4PVnAP9VRRY
5c8An2NW8eTJQT1G39dEg/uLPRDvWnpk
=/2bQ
-----END PGP SIGNATURE-----