Re: Frame ordering

[David Reitter]

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.