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.