Re: GTK+ Mac OS X state of the union

["Jon A. Cruz" <jon joncruz org>]

On Mar 28, 2006, at 9:19 AM, 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:

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)

Wouldn't it be preferable for the developers to just use the Cocoa

menu-creation APIs directly? 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. Or if we had the

equivalent of Qt's QMainWindow, that might be ok too. But (afaik)

we're not talking about that.

One way to look at it might be similar to how Java on OS X has approached this.

By default Java Swing apps being run on OS X have their menus in the windows. However, if they are run with a given property, or have that set in their .jar file, then the menus get repositioned to the top of the screen. There are a few other properties that can change other things. These can also be set from within the program at runtime if desired.

This basically gives developers the option of marking their apps as "mac friendly", and also for end users to decide for themselves if needed, even down to a per-run basis.

I'd say that being able to have the developers sit happy on their Linux boxes doing work, and end users being able to pull and run the apps without mac-specific tuning would be an ideal goal. The less mac-specific work that's needed, the better. Hopefully that can cover the 99% of most common cases.