Hi Fred and Ivan, Am 22.05.2012 08:32, schrieb Fred Kiefer: > I don't think that libdbusmenu-glib is the way to go. We have a > excellent DBUS interface in GNUstep and should build on that when > implementing a theme that wants to handle menus that way.
I second that, especially since the DBusMenu stuff has been on my todo list for quite some time (though not at a very high priority). Basically what you would need is a proxy that exposes the menu using the com.canonical.dbusmenu interface [0] and instead of having gnustep-gui/back doing the drawing and event handling for the menu, you'd register that proxy with the com.canonical.AppMenu.Registrar D-Bus service [1]. The global menu will then issue callbacks that drive the menu. (At least that's my superficial working theory of how it should work) The problem is that DBusKit does not support exposing objects right now, but since there is interest in this from somebody who is not me, I'm now officially motivated/coerced to finally finish that part of DBusKit. Most of the difficult parts are done, but I'm still lacking code that takes care of registering exported objects with the D-Bus daemon. Additionally, a working mapping from NSMenu to dbus-menu might be valuable outside the GTK theme. I think it would be nice to be a bit embracing and also do the integration the other way around, e.g. by modifing the Étoilé menu server to handle the menus for applications written for Ubuntu's global menu. Cheers, Niels [0] http://bazaar.launchpad.net/~dbusmenu-team/dbusmenu/trunk.12.10/view/head:/libdbusmenu-glib/dbus-menu.xml [1] http://bazaar.launchpad.net/~indicator-applet-developers/indicator-appmenu/trunk.0.4/view/head:/src/application-menu-registrar.xml _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
