On Sun 19 Feb 2017 at 12:08:45 -0600, Matthew D. Fuller wrote:
> It happens during the zoom process, in the EWMH case, using the EWMH
> FULLSCREEN priority. Which isn't the max OTP priority, so it sound
> seem that f.zoom'ing an app might not put it on top of everything
> else. It seems like it's also [re]setting that on focus in when it's
> zoomed too, which is... odd. Presumably it's doing that because it
> re-sets it down to EwmhGetPriority() on focus out, which seems even
> wronger. And getting changes in the EWMH_STATE_{ABOVE,BELOW} re-alter
> it as well (ties in with infra).There is this weird stacking order prescribed in https://specifications.freedesktop.org/wm-spec/wm-spec-1.5.html#STACKINGORDER Stacking order To obtain good interoperability between different Desktop Environments, the following layered stacking order is recommended, from the bottom: windows of type _NET_WM_TYPE_DESKTOP windows having state _NET_WM_STATE_BELOW windows not belonging in any other layer windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE focused windows having state _NET_WM_STATE_FULLSCREEN Windows that are transient for another window should be kept above this window. which has the annoying condition focused AND fullscreen... The last sentence implies that even such a fullscreen window may not even be topmost, if it has transients. It has been a while since I looked into it so from time to time it looks weird to me too :-) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
