Re: application class thoughts

[John Ralls <jralls ceridwen us>]

On Apr 5, 2010, at 9:53 AM, Cody Russell wrote:

> On Mon, 2010-04-05 at 11:16 -0400, Colin Walters wrote:
>> There are a lot of secondary goals, like ensuring app-uniqueness,
>> improving remote scriptability, better lifecycle support (when & how
>> to save state), etc., but they're less important I think than the
>> menu. 
> 
> I'm not sure if this relates to the Actions section of the wiki page or
> if it should be done lower-level than this application class, but it
> would be nice to try to get better toolkit-level support for allowing
> global/application menubars to be managed outside the window, for cases
> like MacOSX and such.
> 

Menubars are an interesting problem. The Gtk+ paradigm is that each window has its own menubar, and there is no requirement that different windows' menubars should have the same contents. OSX, on the other hand, normally uses a single menubar for an application. Fortunately, both Cocoa and Carbon allow this menu to be switched at will, so it's easy to follow the Gtk+ paradigm with a focus signal handler. Carbon has a problem with the App menu because there's only one, so one can't just use the usual "emit the GtkMenuItem action signal" approach; the GtkMenuItem goes away when the window is destroyed. Fortunately, Cocoa has a separate App menu for each mainMenu, so that particular problem goes away.

Regards,
John Ralls