Re: Should this package be included into the NS port?

[Nick Helm <nick@tenpoint.co.nz>]

On Sat, 19 May 2018 at 07:36:32 +1200, Alan Third wrote:

> There are two problems, though.
>
> * Application Menu
>
> When the last NS frame is deleted the menus aren’t updated, so I think
> they’ll be the menus as defined for the last frame. They should
> probably be cut right back to just the ‘Emacs’ menu, and perhaps
> ‘help’.

This is interesting. I think we could tweak the EmacsMenu side of things
to do this, even with the current code. We'd want to make sure to
include some kind of new frame command somewhere.

These menus are derived dynamically from Lisp though, and it might be
difficult to convince it to provide valid entries when no frame is
selected. 

One way around that might be to create a new menu containing
static NSMenu versions of File and Help, much like we do for the appMenu
now. When no frame is selected and there are no Lisp menu entries, we
switch mainMenu to this new menu. When a frame is created, we switch
back. 

A side benefit would be that we can set File and Help to anything
we want, e.g. add a new frame command and fix up the quit duplication.

> * Dock Menu
>
> This has a ‘new frame’ option but just plain doesn’t work. I think the
> problem is the way it’s trying to create a new frame:...
>
> This seems to rely on there being an existing NS frame, but we’ve
> deleted the last one. I assume if we were clever we’d be able to use
> the, still open, terminal frame.

With all of this discussion, I feel like I'm missing something really
fundamental. Putting emacsclient aside for a moment, if we were dealing
with a standard Cocoa app, the window server and NSApp loop would keep
running in the background and we could close everything, then create a
new frame (as a view on an NSWindow instance) as needed.

How is the architecture of Emacs on NS so different from standard Cocoa
that these kinds of workarounds are necessary?