Re: Re: _NET_WM_STATE_ABOVE and _NET_WM_STATE_FULLSCREEN
- From: Sam Spilsbury <smspillaz gmail com>
- To: Martin Gräßlin <mgraesslin kde org>
- Cc: wm-spec-list gnome org
- Subject: Re: Re: _NET_WM_STATE_ABOVE and _NET_WM_STATE_FULLSCREEN
- Date: Sun, 29 May 2011 21:27:18 +0800
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.
--
Sam Spilsbury
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]