Re: OSX Menu Integration

[John Ralls <jralls ceridwen us>]

On Nov 28, 2009, at 10:57 AM, Paul Davis wrote:

> On Wed, Nov 25, 2009 at 6:25 PM, Cody Russell <bratsche gnome org> wrote:
>> On Wed, 2009-11-25 at 17:52 -0500, Matthias Clasen wrote:
>>> 
>>>> 7. menu export over D-Bus [bratsche]
>>>> - useful for ubuntu's "application indicators"
>>>> - Quartz backend
>>>> - menu reflowing
>>>> - bratsche is working on a general purpose menu proxy
>>>> - 3.0 material
>>> 
>>> Is this based on proxying actions over dbus, or widgets ?
>> 
>> Uh, well both I guess.  The original idea was to create a menu proxy
>> interface that's implemented via a GTypeModule, so that module could
>> implement OSX-specific functionality on Mac or it could implement
>> something using dbus.  This would modify GtkMenuShell or something so
>> that if it has a proxy module loaded then it would be able to push items
>> to the proxy and listen to events from them.  I've got the code for this
>> bootstrapped already, but need to flesh it out some more still.
>> 
>> Then I thought this could also be useful for dealing with menubar
>> overflow, so that the menubar could dump additional menus/menuitems into
>> the overflow area and get events on them without having to reparent
>> anything.  This shouldn't depend on any system-level features like
>> Quartz or dbus though, so I probably need to generalize the code I've
>> got a little more to make it useful for this case as well.
> 
> this may be significantly more complex than you are imagining.
> 
> on OS X it is not only necessary to push the items to a proxy (in this
> case, the main menu bar at the top of the display), but also to push
> events there too. the needs of applications in this regard vary -
> simple applications can probably get away with a default or at worst a
> single function to say "forward window events to menu proxy". however,
> for more complex apps (gimp, ardour, beast), this isn't true - they
> need the event forwarding done in a rather application specific way. i
> have a patch for gtk/gdk/aqua that provides this, but it is very hard
> for me to imagine it being built in to a generic menu proxy system.
> 
> also, as a side note: this stuff is one of the few areas where
> gtk/gdk/aqua uses the carbon API and thus prevents 64 bits builds for
> snow leopard.

Indeed, the present menu translation code (http://github.com/jralls/ige-mac-integration/blob/master/src/ige-mac-menu.c) runs over 1200 lines -- and still has issues with the "app" menu (the one all the way on the left having the same name as the application) for multi-windowed apps. Gimp uses an older version of this code which they've added directly to their codebase. 

It does indeed use Carbon at present. I've looked at rewriting it for Cocoa and have in mind a strategy to try, but I first want to get the mutli-window app menu fixed as it makes a rather ugly bug in Gnucash for users who prefer mutltiple windows  to notebook tabs.

A large portion of the current code is actually caused by it's being carbon based, as carbon menu items aren't objects that one 
can store a pointer to. They're entries in an opaque container and one accesses them by a pointer to the container and an index. Maintaining the synchronization between the index and the gtkmenuitem object involves a good 2/3 of the code in ige-mac-menu.c. Little of that will be needed for a Cocoa implementation where NSMenuItem is an Objective-C class with a straightforward OO callback mechanism.  I'll start work on such an implementation as soon as I finish with the multi-window problem in the Carbon code. 

I think that even more simplification could be achieved by moving the Cocoa code into a new gtkmenushell-quartz.c and gtkmenuitem-quartz.c since that would remove the need for syncronization at all. I'll look at that as part of the Cocoa work. 

Cocoa also provides for delegation of event handling on a per-window basis, but I'm not sure how this would be germane to menu integration if it were done inside of gtk.

Regards,
John Ralls