discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DBus Menu in Gtk theme


From: Dr. H. Nikolaus Schaller
Subject: Re: DBus Menu in Gtk theme
Date: Mon, 11 Jun 2012 21:18:47 +0200

Are you sure they are really compatible?

DO forwards NSInvocations (incl. all parameter objects) to a remote
end identified by a NSMach or NSSocketPort and returns results. It
has provisions for specifying whether objects are transported byref
or bycopy to optimize performance.

I have no very deep knowledge in DBus but my impression is that
it has a different remote object addressing scheme and message
model that is incompatible with NSInvocation forwarding.

But I may be wrong and there may be a clever way to define a
subclass of NSDistributedObject or something similar that references
a DBus "objet" and can be easily used as an argument of on NSInvocation.

Then, the "rootProxy" could reference DBus remote objects.

Just my 2 ct,
Nikolaus


Am 11.06.2012 um 21:08 schrieb 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"
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep




reply via email to

[Prev in Thread] Current Thread [Next in Thread]