Re: maintaining key window on unhide

[Matt Rice]

--- Fred Kiefer <fredkiefer@gmx.de> wrote:

> Hi Matt,
> 
> sorry for not commenting earlier, but I am currently
> a bit ill and avoid
> writing mails when possible.
> But as you want to commit, I better put in my ideas
> now.
> 
> First it is great that you started to look at this
> and your general
> implementation looks like a great way to do it.
> There are a few details
> which I want you to reconsider.
> 
> - There are already functions in NSWindow.m, e.g.
> NSWindowList(), which
> are supposed to return the windows in front to back
> order. Perhaps it
> would be possible to redirect these function tot he
> display server and
> implement the rest on top of them.
> 

aha, i was unaware of this function, then thats
probably what GSDisplayServer -windowlist was intended
for :D

> - There is also a method in GSDisplayServer
> windowlist, which could be
> defined to return the window ordered and implemented
> the way you want
> it. If not, lets remove this method.

yeah, i'll switch windowsordered to windowlist then.

> 
> - You use the new GSDisplayServer method in various
> methods on
> NSApplication. I would prefer that we just use it,
> or which ever other
> solution you choose, in orderedWindows and use the
> later method
> everywhere else. Making this method the official
> interface for ordered
> windows.

ok, i just used the windowsordered as -orderedWindows
was documented as a 'scripting method', after looking
at the documentation it needs some more work, it
should ignore NSPanels, and 'non-scriptable-stuff',
and after adding that I'm not sure we'd want to rely
on it as the official interface.

> - Your implementation of GSDIsplayServer
> windowsordered returned the
> windows ordered the other way round as
> orderedWindows has to return
> them. Why not resolve this at the level below and
> just pass the values on?

well, this all has to do with
orderWindow:NSWindowBelow relativeTo:... seeming not
to work, i'm not entirely sure if its a GNUstep
problem or a window manager problem.

so that requires hide: and deactivate to orderFront:
from back to front.

so either way we currently have to iterate in reverse
some places..

but there are 3 methods that want front->back and 2
which require back->front currently, so i'll just swap
it to font->back .. its all kindof a mess.

> 
> - It should also be possible to implement
> orderedDocuments on top of
> orderedWindows.

ok, i don't really have any idea how this ones
supposed to be implemented.

> 
> - 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,

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.

> 
> - There is an unrelated change to NSView.m included
> in this patch.

yeah was just to get rid of a warning about NSCursor
not responding to retain which was annoying me.

> 
> Hope this long list is not frustrating your. I think
> your change is
> worthwhile the effort of another rewrite.
> 

nope, all good points.


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