Top-most windows

Keith Packard keithp at keithp.com
Mon Jan 9 17:38:56 PST 2006


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.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-arch/attachments/20060109/875fd4bd/attachment-0001.pgp


More information about the xorg-arch mailing list