Re: Frame ordering

[David Reitter <david.reitter@gmail.com>]

On Jun 14, 2010, at 12:05 PM, Lennart Borgman wrote:
> 
> What is the reason not to let the window handler do this job? Why
> should Emacs do it?

Absolutely.  Up to now I've been going by the comment quoted elsewhere in this thread, stating that we'd have to do it ourselves.  

On Jun 14, 2010, at 9:29 AM, Stefan Monnier wrote:

> So we should start by removing this NS-specific #ifdef.


When I take out the NS-specific raise-frame call, the new topmost window fails to become active (key/main) after deleting a frame.  That is why we need to call raise-frame.  However, we should do so with the topmost window (rather than one determined via Vframe_list).  This is more rather than less NS-specific code.

Second, this would not affect the cycling at all.  As far as I can see, Cocoa applications use a _cycleWindows method from NSApplication, but that one is private.

NSApplication's `orderedWindows' is basically what we want.  So I would probably suggest to implement a port-specific variants of `prev_frame()', which then use the window manager's list or, if available, call any window manager API directly.