Re: Frame ordering

[David Reitter]

On Jun 15, 2010, at 9:25 AM, Stefan Monnier wrote:
> 
> I think we first need to figure out how to fix the bug that the
> Fraise_frame is trying to workaround.  And then we'll see if further
> changes are required.


I'm not sure how fixing Fdelete_frame can possibly address the issue concerning 
the next/previous-frame order.  
Of course you're right that this is odd and that there probably is a bug 
somewhere.

delete_frame() first selects another frame before running the terminal's 
delete_frame_hook.  Does this make the new frame the NS key frame?
If we are not deleting a key frame, I reckon NS will not select another frame 
to make it key.    [NSWindow close] is called in nsterm.m's 
x_destroy_window()), and I think it should change the key frame if the key 
frame is being deleted, as [NSWindow orderOut] is documented to do.

The Appkit port does this only slightly differently:

  /* AppKit version of mac_dispose_frame_window, which is implemented
     as -[NSWindow close], will change the focus to the next window
     during its call.  So, unlike other platforms, we clean up the
     focus-related variables before calling mac_dispose_frame_window.  */

mac_dispose_frame_window (f)
     struct frame *f;
{
  NSWindow *window = FRAME_MAC_WINDOW (f);

  [window close];
}

However, the delete_frame() function in frame.c is the same - it seems to 
select some other frame according to Vframe_list:

On Jun 15, 2010, at 5:24 AM, YAMAMOTO Mitsuharu wrote:

> 
> That would be the behavior of "letting the window manager decide",
> i.e., no explicit code at the application side.  The Mac port also
> behaves like this.

Can you point out how your port does that?  I can't find it.  (If it is a 
recent change, let me know and I'll update my Appkit branch.)