Re: GTK+ Mac OS X state of the union

[Michael L Torrie <torriem chem byu edu>]

On Tue, 2006-03-28 at 12:19 -0500, Dominic Lachowicz wrote:
> I'm sorry for what may be a stupid question. Why do we need a bridge
> API (assuming that there's a 1:1 mapping between Cocoa and GTK+ menus)
> if we're already putting the onus on developers to:

You know, I don't know.  I do know there's probably not a 1:1 mapping
between Cocoa and GTK+ menus.

> 
> 1) Modify their menus to conform to MacOS style guidelines, including
> putting entries into special menus (e.g. the "Apple" menu), which
> don't have a GTK+ equivalent
> 2) Call GTK+-MacOS specific APIs to inject the menus into the OSX menu bar
> 3) Call #2 at appropriate times when different windows get focus (e.g. the Gimp)

Well in the case of 3, Mac users do not expect a menu to change just
because they switch windows within an application.  The menu should
always remain constant.  How well GTK apps can be adapted to this
paradigm I don't know.

> 
> Wouldn't it be preferable for the developers to just use the Cocoa
> menu-creation APIs directly? 

That is probably a good idea.  I don't know enough about Cocoa and Gtk
and how they would interact to comment more.  You're right, though.
This is probably a better idea than any shims.

> If we were talking about some shim that
> automatically takes any focussed window's GtkMenuBar and injects it
> into the OSX menu bar, that might be different.

I believe that simply taking the focused window's GtkMenuBar is
impractical because there's nothing that says that an window must only
have one GtkMenuBar.  It could have several. Which one do you use?
Further, what do you do when there is no window?  What about apps like
Gimp where the "main window" isn't really the focus and shouldn't be the
menu you want up.  Typically OS X apps have one menu only, no matter
which window is displaying.

>  Or if we had the
> equivalent of Qt's QMainWindow, that might be ok too. But (afaik)
> we're not talking about that.
> 
> Best,
> Dom
>