Top-most windows
Deron Johnson
Deron.Johnson at Sun.COM
Tue Jan 10 09:41:19 PST 2006
Keith Packard wrote On 01/09/06 17:38,:
> On Mon, 2006-01-09 at 14:07 -0800, Deron Johnson wrote:
>
>>Deron Johnson wrote On 01/09/06 13:35,:
>>
>>
>>>Perhaps having a simple concept like "I am the composite
>>>manager. I rule the screen real estate" is a simpler, more direct
>>>concept.
>>
>>Note that we can avoid all of the issues of "how does a window manager
>>handle topmost windows" if we introduce a new mode, such as, "take
>>this window and make it the priority window until I tell you otherwise
>>or destroy the window." The priority window is defined to always be
>>on top of all other windows except screen saver windows. To implement
>>this concept we can leverage the screen saver implementation as
>>Keith suggested. This concept has virtually no visibility to window
>>managers at all; they don't need to worry about it.
>
>
> Actually, having a request which created a window as 'topmost', and
> making those invisible to all window management requests would avoid
> window manager issues; they'd be implicitly OverrideRedirect and live in
> their own stacking order. By eliminating the 'mode switch' mechanism, we
> eliminate all of the nasty semantics around disappearing/reappearing
> topmost windows.
>
> Allowing only one such window would make this marginally simpler to
> manage inside the server; it would then have to deal with the potential
> of two such windows (explicit topmost and screen saver), which might be
> easier than dealing with multiple such.
>
> Allowing it only at the root level would leverage more of the existing
> screen saver-based implementation, but there are few other root-specific
> operations like this.
>
>
>>This idea has the same simplicity and ease-of-implementation as the
>>topmost window concept but without any of the gnarly window manager
>>issues. Plus it is a feature which is associated with the composite
>>extension, which is good because it is mostly composite managers
>>that are going to want to use it.
>
>
> We could still stick this in XFixes instead.
Whether it is a "topmost" window or a "composite priority" window, I am
strongly in favor of it. It solves all of the known problems, not just
some of them and it is clean and easy to implement. And it doesn't
require significant changes to OpenGL, which we have less control over.
I believe that the issues surrounding topmost window semantics can be
mitigated.
More information about the xorg-arch
mailing list