Re: maintaining key window on unhide

[Matt Rice]

--- Matt Rice <ratmice@yahoo.com> wrote:

> 
> 
> --- Fred Kiefer <fredkiefer@gmx.de> wrote:
> > 
> > - Why are deactivate and unhide processed in
> > stacking order?
> 
> i think you mean deactivate and hide,
> they just save the hidden windows in order in the
> _hidden and _inactive arrays, because when they are
> ordered out they are no longer in the
> _NET_CLIENT_LIST_STACKING stuff,
>  co
> then unhide/activate use this to orderFront 
> back-most object first front-most object last
> 
> in the saved order.
> again because of orderWindow:NSWindowBelow
> relativeTo:.
> 
> ideally it should all be done in front->back
> ordering the front first, then everything behind the
> previously ordered window.
> 

I took a little look into this, 

it seems as though orderWindow:relativeTo: actually
does work in certain cases, e.g. when called from a
button action and both windows are ordered in.

it seems to typically be ignored when one the
receivers is not mapped

because XReconfigureWMWindow seems to call 

XConfigureWindow, which returns a BadMatch error if
the windows are not siblings.

in this case one is likely been reparented to the
window managers frame or something.

so XReconfigureWMWindow traps the error and forwards a
ConfigureRequestEvent to the window manager,

which i afaict ignoring the request because it is not
managing the window.

and to compound things it seems that if its being
called in the NSAppIconView -mouseDown: some other
strangeness occurs, even if the windows are already
mapped.. they lose their window decorations.. 
no ideas about this one.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com