Re: DBus Menu in Gtk theme

[Jamie Ramone]

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 <niels.grewe@halbordnung.de> 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 <niels.grewe@halbordnung.de
>> <mailto:niels.grewe@halbordnung.de>> 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
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

-- 
Besos, abrazos, confeti y aplausos.
Jamie Ramone
"El Vikingo"