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 <mgraesslin kde org> wrote:
> > On Sunday 29 May 2011 19:26:05 you wrote:
> >> On Sun, May 29, 2011 at 7:13 PM, Martin Gräßlin <mgraesslin kde org> 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

Attachment: signature.asc
Description: This is a digitally signed message part.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]