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: Niels Grewe
Subject: Re: DBus Menu in Gtk theme
Date: Wed, 23 May 2012 13:48:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4

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



reply via email to

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