Just my 2 cents but wouldn't it be better to integrate DBus awareness into the DO related classes (NSConnection, NSDistantObject, etc.) as it's basically the same thing but written in C? I recently had to work with DBus for the first time a few months ago and was astonished at how similar it was to DO, and how it basically duplicated both GNUstep's and Apple's effort in object oriented inter-process communication, though failing a bit in the transparency dept. So what I'd suggest is adding code to transparently handle communication with DBus endpoints (I hesitate to use the word 'object' here). I believe all that would be needed is to add detection code for an incoming connection request to distinguish whether the solicitor is a GNUstep object or a DBus endpoint for a server, and something analogous for a client (detecting the server type, most likely via handshaking). With a mechanism like this in place communication with DBus capable apps becomes trivial.
On Wed, May 23, 2012 at 8:48 AM, Niels Grewe <[email protected]> wrote: > Hi Ivan, > > Am 23.05.2012 13:35, schrieb Ivan Vučica: >> Hi, >> >> On Tue, May 22, 2012 at 3:57 PM, Niels Grewe <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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) >> >> >> DBusKit would definitely be the cleanest way to go. >> >> However, an issue is possible breakage of the DBus interface on >> Canonical's part. libdbusmenu-glib is probably less likely to be break. > > I don't think that is an real issue. If Canoncial (or, for that matter, > any other company or project) defines and documents an API, I'd expect that > > a) the reference implementation actually adheres to the documentation > b) it is kept stable for the forseeable future > c) deprecation of functionality and other API changes only happen if > there is a sensible reason for them and are communicated well in advance > > If you expect Canonical to be silly enough to not do that, I'd not even > bother implementing the API at all. Otherwise, I'd prefer having a > proper Objective-C solution for this. > > Cheers, > > Niels > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Besos, abrazos, confeti y aplausos. Jamie Ramone "El Vikingo" _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
