--- Matt Rice <[EMAIL PROTECTED]> wrote:
> > > --- Fred Kiefer <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnustep
