Finishing Composite to handle transformed windows

Carsten Haitzler (The Rasterman) raster at rasterman.com
Fri Jan 6 21:29:22 PST 2006


On Fri, 06 Jan 2006 16:30:37 -0800 Deron Johnson <Deron.Johnson at Sun.COM>
babbled:

> 
> 
> Keith Packard wrote On 01/06/06 14:24,:
> 
> > If we're really going to support this in earnest, I suggest that all of
> > the usual configuration functions should work as if there were two
> > separate stacks of windows, the 'normal' and the 'topmost', so you
> > should be able to raise or lower topmost windows within the topmost set
> > using the normal set of operations. When a window is moved from 'normal'
> > to 'topmost', it should be placed at the bottom (?) of the topmost set.
> > Similarly, when moved from topmost to normal, it should appear on the
> > top of the normal windows.
> 
> Yes. The concept of a "topmost window stack" seems more general and it
> defines reasonable semantics for multiple top-most windows.
> 
> Here are some suggested rules:
> 
> 1. Windows in the topmost window stack always are displayed above
>    windows in the normal stack.
> 
> 2. A TBD request is called to move a window from one stack to another.
> 
> 3. The ConfigureWindow protocol request only restacks the given window
>    within its current stack. Expose and ConfigureNotify events are sent
>    as usual. If the override-redirect attribute is False and some other
>    client has selected SubstructureRedirectMask on the parent, the X
>    server generates a ConfigureRequest event to that client and no
>    restacking occurs.
> 
>    Note: not all window managers may know how to handle properly handle
>    a ConfigureRequest event that is generated for a restack operation
>    within the topmost window stack, so it is recommended that windows
>    in this stack always have their override redirect attribute set
>    to True.
> 
> 4. The CirculateWindow protocol request only restacks the given window
>    within its current stack. Expose and CirculateNotify events are
>    sent as usual. If the override-redirect attribute is False and some
>    other client has selected SubstructureRedirectMask on the parent,
>    the X server generates a CirculateRequest event to that client and no
>    restacking occurs.
> 
>    Note: not all window managers may know how to handle properly handle
>    a CirculateRequest event that is generated for a restack operation
>    within the topmost window stack, so it is recommended that windows
>    in this stack always have their override redirect attribute set
>    to True.
> 
> 5. If the highest window in the normal window stack is moved to the
>    topmost stack, no events are generated.
> 
> 6. If the lowest window in the topmost stack is moved to the normal
>    stack, no events are generated.
> 
> > I don't know precisely what events should be triggered when windows move
> > between topmost and normal stacks; we can either ignore the problem and
> > generate no events, we can pretend they're getting reparented, or we can
> > pretend they're getting destroyed/recreated. (See rules #5 and #6 above).
> 
> Moving the highest normal window to the topmost stack and moving the
> lowest topmost window to the normal stack is tantamount to no stack
> change at all. It's effectively a no-op, as far as normal standard X11
> events are concerned. So I would suggest that these operations generate
> no events at all.

i would disagree - moving from normal to topmost should move the window to the
top of the topmost stack to be equivalent to creation in the topmost stack (ie
- on top)... but you are right that moving bottom most "top most" window to
normal stack would be a no-op.

> > Another question is whether it is valid and useful to allow
> > non-overrideRedirect topmost windows. I suggest that we should allow
> > this, but that we note that existing window managers are unlikely to do
> > anything useful with these windows, and in fact without knowledge that
> > the window manager will work correctly, applications are probably better
> > off not creating such windows.
> 
> This seems reasonable to me. (See the notes for rules #3 and #4 above).
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)



More information about the xorg mailing list