GNOME Bugzilla – Bug 711504
Specify D-Bus protovol for exported GMenuModel
Last modified: 2017-11-23 09:45:08 UTC
Hi, it seems that the dbusmenu spec is old and busted, and GMenuModel is the new hotness. That’s OK, but there’s a regression. dbusmenu had a spec, but the doc for g_dbus_connection_export_menu_model says: > These functions support exporting a GMenuModel on D-Bus. The D-Bus interface that is used is a private implementation detail. The second sentence point out a serious regression, because the absence of a spec makes everyone not depending on glib unable to support the protocol. D-Bus is for IPC in a programming language and environment agnostic way, which is totally contradicted by hiding a spec away as an “implementation detail”. So please, create and freeze a D-Bus protocol spec for exported MenuModels so that the rest of the world can be compatible with you. The old spec was pretty awesome since the person responsible Qt and GTK+ examples, and it was able to be used without toolkit: https://code.launchpad.net/~agateau/libdbusmenu/spec I’d like to see the same features with the new way again.
This is the wrong place to ask for a "spec" (some freedesktop.org thing probably is). Also, you're wrong about D-Bus - it's perfectly fine to use as just a private implementation detail. Further, my personal view is that it doesn't make much sense for GLib developers to write a spec if you only have a single implementation ... and it also takes away a lot of freedom for GLib developers to fix bugs, innovate and so on. Anyway, I'm currently pretty disconnected from GLib development so I'm not going to close this NOTABUG/WONTFIX ... so there's that :-)
what i wanted to say isn’t that D-Bus shouldn’t be used as implementation detail, but that it’s sad when a open, stable, documented, and compatible spec that makes multiple free desktop projects happily work together in the present is thrown away in favor of something laconically declared as “implementation detail”. if they want to innovate and create a new protocol & implementation to eventually replace the old one: fine. then let’s hide it behind a compatibility layer by only (or additionally) exposing and consuming the old libdbusmenu protocol. but i agree. let’s create a neutral-namespace freedesktop standard/recommendation. if it’s not ready for that yet, that’s OK, but then it must be clear that creating this spec has to be a major goal of all the effort poured in here. that the “implementation detail” status is unwanted and a temporary solution.
GMenuModel is not a replacement for dbusmenu and as such it's a bit strange to speak about "regressions" between the two of them. We currently have absolutely no plan to document this D-Bus interface. There may very well be changes in the future and keeping flexibility here is important to us. Making this interface private was an intentional design decision.
> GMenuModel is not a replacement for dbusmenu interesting, so i can still expect menus in GTK+ applications to work with KDE’s dbusmenu consumer and those of Qt applications to work with GNOME shell’s and unity’s appmenu / global menu? unfortunately, that doesn’t seem to be the case. should i file a bug? > We currently have absolutely no plan to document this D-Bus interface. There > may very well be changes in the future and keeping flexibility here is > important to us. Making this interface private was an intentional design > decision. as long as it doesn’t replace dbusmenu and everything is still compatible with it, that’s fine.
(In reply to comment #4) > > GMenuModel is not a replacement for dbusmenu > > interesting, so i can still expect menus in GTK+ applications to work with > KDE’s dbusmenu consumer and those of Qt applications to work with GNOME shell’s > and unity’s appmenu / global menu? > > unfortunately, that doesn’t seem to be the case. should i file a bug? Not here, at least. dbusmenu is not an upstream api that we support.
So am I right that it was just a Ubuntu patch that made GTK applications work with dbusmenu consumers, and you (GNOME and Ubuntu developers) decided to do GMenuModel instead? If that’s the case I apologize for false assumptions, but insist that it’s a step back; a regression in interoperability that way possible using dbusmenu. I intend to help fixing that and ask the people who made that decision: You must have had good reasons why you didn’t choose to support the dbusmenu protocol and developed a different one instead. So please specify where exactly dbusmenu was lacking and what the internal protocol is capable of compared to dbusmenu. This will be a starting point to develop an extended Menus-over-DBus spec that fulfills your needs (and likely also everyone else’s, since I haven’t heard anyone complaining about dbusmenu)
dbusmenu was never proposed upstream as a supported protocol or API: it's a Ubuntu-only/Unity-only patch applied downstream. GMenuModel was implemented to provide functionality for GNOME and MacOS portability. Bugzilla is not the right place to discuss about this; please, use gtk-devel-list instead.
The decision to stop using dbusmenu and start with GMenuModel was made internally by Canonical management. It's _really_ out of scope for chatting about here, on GNOME's Bugzilla.
Sure, I just wanted to bring this to its logical conclusion so that googlers find a pointer that this discussion is continued on the GTK-devel mailing list. See you there.