Re: GTK+ Mac OS X state of the union

["Dominic Lachowicz" <domlachowicz gmail com>]

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.

Best,
Dom

On 3/28/06, Michael L Torrie <torriem chem byu edu> wrote:
> On Tue, 2006-03-28 at 11:44 -0500, John Ehresman wrote:
> > A separate api is probably needed.  OS X applications can and should
> > display menu bars when no top-level windows are open.  Also the
> > preferences, quit, and possibly other items should be on the menu with
> > the applications name on it instead of the file menu.
>
> Since preferences and even quit could be anywhere, the app developer
> would have to create a mac-specific GtkMenu object that followed the OS
> X guidelines and then throw that up.  I think putting the burden on the
> developer in this thing isn't too bad.  The Gtk main routine could even
> be patched to display the initial application menu (with its name).  The
> developer would then put assemble the rest of the menu and throw it up
> with this API.  I haven't done any development work on GTK itself since
> the 1.2 says, so I can't really say how the best way to actually
> implement any of this is.
>
> What do any GTK developers think of a small API to bridge this gap?
>
> >
> > I'm assuming that the goal is an application that looks & feels as
> > native as possible and not to replicate the X11 / gnome look & feel.
> > Both are reasonable goals, but I suspect that more OS X users want
> > native look & feel.
>
> A good start is a normal OS X menu bar.  Then work on the look and feel
> of the actual application windows.
>
> A long time down the road too, modal dialog boxes could be implemented
> OS X-style, sliding out the title bar of the parent window.
>
> If somehow GTK became a first-class OS X developer toolkit, I think that
> would be wonderful.
>
> I'm not clear if GTK for OS X is using carbon or cocoa for drawing.
> Carbon is easiest to use from C, but Cocoa is better in the long run
> (handles OS X-isms like Command-clicking unfocused windows and scrolling
> better).
>
> >
> > Is it possible to build gtk for native OS X via jhbuild?
> >
> > John
> >
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>


--
Counting bodies like sheep to the rhythm of the war drums.