DBus Menu in Gtk theme

[Ivan Vučica]

Hi all,

Since I recently installed Ubuntu 12.04, I'm only now familiarizing myself with development on desktop environments.

Unity's global menu looks quite cool. Looks like we could plug into it over DBus.

  https://launchpad.net/dbusmenu

It'd prevent adding custom views as menu subviews and any custom painting of menus, but that probably won't affect many apps (and would be optional as part of the Gtk theme, anyway).

Any thoughts?

--
Ivan Vučica - iv...@vucica.net

[Gregory Casamento]

Ivan,

I have been working on a way to get native menus into the Gtk theme
for a while now. Many of the approaches have been less than perfect
because it involves reparenting of a window into a subview for display
of the menu.

If this can work without this kind of kludge it would be ideal!
Please let me know what you find out and keep in contact with me and
the group. I'd be fascinated to hear what you discover!

GC

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>



--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com

[Ivan Vučica]

I did a tiny bit of investigation here, and for purposes of integrating with Ubuntu (but not bringing in native Gtk menus, I'm afraid) -- we can make use of libdbusmenu-glib. We could probably use DBusKit too, and send dbus messages directly, but that way we might be risking breakage more than if we use a Canonical-supported wrapper library.

Some useful code is in "java-swing-ayatana" project. If I extract their code into an easily understandable minimal example of making use of libdbusmenu-glib, I'll update the group.

[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. Please have a
look at DBusKit before starting any other implementation on this issue.
DBusKit was implemented during GSoC by Niels Grewe two years and is
still maintained by him.

Fred

[Niels Grewe]

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

[Ivan Vučica]

Hi,

On Tue, May 22, 2012 at 3:57 PM, Niels Grewe <niels...@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.

[Niels Grewe]

Hi Ivan,

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

[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.

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

--

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

[Dr. H. Nikolaus Schaller]

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

[Niels Grewe]

Hi Jamie,

Am 11.06.2012 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.

That's not quite true. D-Bus does a few things quite differently, for
example, the name service and the handling of notifications ("signals"
in D-Bus parlance) are quite different, so is the type-system (which,
for instance, does only have a very limited way to reference and pass
objects around) I have a writeup on the differences in the first chapter
of the DBusKit manual.

> So what I'd suggest is adding code to transparently handle communication with
> DBus endpoints (I hesitate to use the word 'object' here).

My personal opinion is that the API in DBusKit is as transparent as is
sensible (though this opinion might be quite biased because I wrote
it…). Setting up a reference to a remote D-Bus object is largely
equivalent to DO:

DKPort *sPort = [[DKPort alloc] initWithRemote: @"org.freedesktop.DBus"
onBus: DKDBusSessionBus]
NSConnection *c = [NSConnection connectionWithReceivePort:
[DKPort sessionBusPort]
sendPort: sPort];

id proxy = [c proxyAtPath: @"/org/freedesktop/DBus"];
[proxy doSomething];

I don't see where the added value of not blurring the distinction
between DO connections and D-Bus connections comes from.

Cheers,

Niels

[Ivan Vučica]

On Tue, May 22, 2012 at 3:57 PM, Niels Grewe <niels...@halbordnung.de> wrote:

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.

Just checking: was some work done here? 

[Niels Grewe]

Hi Ivan,

Yes, quite a bit, though mostly under-the-hood stuff. Registration of
objects is working and they can be messaged from other D-Bus peers. The
problem is that at the moment, you kinda would have to hand-craft the
information required by DBusKit to map Obj-C methods to D-Bus methods. I
have bits of code here and there that automates this, but I didn't get
to around to bringing it into a usable state.

Also WIP are D-Bus property support and outgoing notifications/signals.
IIrc, you need the latter for DBus menus. I hope that I'd be able to
work more on that soon.

Cheers,

Niels

[Ivan Vučica]

I've played a bit more with DBus Menu, and I've accidentally stumbled upon what's been causing my 'minimal' example of creating a 'global menu' not to work.

The issue? Standalone items apparently cannot exist in the dbusmenu's root. They must be actual menus, with subitems, it seems.

So, I'm happy that the little devil finally works. It's terribly ugly, but it works.

    https://bitbucket.org/ivucica/mini-dbusmenu

This doesn't, of course, help with GNUstep, considering the consensus is that DBusKit should be used instead of hacks with glib and its main loop. 

But the following code from Enlightenment might:

    http://git.enlightenment.org/core/elementary.git/plain/src/lib/elm_dbus_menu.c?id=f13463da05b76d962c5b73f4706d137a3f76ef22

Considering it seems to use their own DBus implementation, and does not seem to reuse any Canonical's components, or Gtk or Qt, it might be helpful in figuring out the protocol. On the other hand, someone who understands DBus better than I do (at the moment) might not need that, either; to me personally, Canonical's documentation about the protocol when talking over DBus was not extremely helpful. 

'Java Swing Ayatana' project contained more useful code when it comes to integrating glib version of libdbusmenu.

And Enlightenment seems to contain code useful when talking directly over DBus, without Canonical's wrapper.

[Niels Grewe]

Happy new year everybody!

I’ll just do my own bit of ‘thread necromancy’, as Ivan adequately put it. I finally found the time to hack a bit more on this D-Bus menu thing. I originally started working on this back in the summer at the Cambridge hackathon. It took me a while to find enough time to get all the bits and pieces in order, but I finally have a partially working implementation of Canonical’s global menu protocol. Please see [0] for a screenshot of Ink running with a theme that delegates displaying the menu to the Ubuntu menu server. Unfortunately, it’s not very useful at the moment, because I haven’t implemented sending signals/notifications from DBusKit out to other D-Bus objects. This is required to keep the menu server updated about the current status of the menu, so by the time you start interacting with the menu, the structure is out of date and ends up getting a bit messed up, so many of the menu items won’t work properly. Still, it’s a pretty good start (and resulted in quite a few improvements and bugfixes to DBusKit!) and I intend to add the few missing parts soon, so that it becomes actually usable.

If you want to check it out in the meantime, please update to the latest trunk version of -gui -back and dbuskit. The bundle that proxies the menu to D-Bus is located in ./Bundles/DBusMenu, and there is an example theme in ./Examples/GlobalMenu that shows you how to integrate the global menu into a theme.

Cheers,

Niels

[0] http://www.halbordnung.de/~thebeing/gnustep/global-menu-ink.png

[Ivan Vučica]

Niels,

You're my hero.

Looking forward to studying how this works. :-)

[Markus Hitter]

Am 01.01.2014 21:09, schrieb Niels Grewe:
> [0] http://www.halbordnung.de/~thebeing/gnustep/global-menu-ink.png

Wow, that's magnificent!

--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.reprap-diy.com/
http://www.jump-ing.de/

[Fred Kiefer]

Happy New Year!

And thank you very much for working on this. It already looks very impresive,

Fred

On the road

[Gregory Casamento]

Niels,

What a great happy new year surprise. David and I were just talking about this. :)

Thanks for working on this. Very nice work!

Greg