GNOME Bugzilla – Bug 622883
[meta] Migrate from dbus-glib to glib's GDBus
Last modified: 2018-09-21 17:04:26 UTC
For GLib 2.25.5 GDBus D-Bus support was merged, providing an API to replace dbus-glib. See http://library.gnome.org/devel/gio/unstable/gdbus.html and http://library.gnome.org/devel/gio/unstable/ch28.html . According to a quick grep this module seems to use dbus-glib: ./gvfs/configure.ac: PKG_CHECK_EXISTS(dbus-glib-1 bluez >= 4.0, msg_obexftp=yes) ./gvfs/configure.ac: PKG_CHECK_MODULES(OBEXFTP, dbus-glib-1 bluez >= 4.0)
Assigning to myself, started working on this.
I strongly suggest to use gdbus-codegen(1) for this - see http://people.freedesktop.org/~david/gdbus-binding-tool-20100902/ for latest codedrops (all this will be in GLib 2.27/2.28). Especially in the remote volume monitors, GDBusObjectManager is useful as is GDBusProxyManager for the client side bits connecting to remote volume monitors (in particular GDBusProxyManager handles all the icky issues with the service coming and going).
The important thing is that the GIO modules have as few deps as possible.. because all GIO using apps will be have the union of all these deps. FWIW, Ideally this means only the GLib library stack itself (which includes GDBus)... which I actually think is a goal we can meet. (In reply to comment #0) > ./gvfs/configure.ac: PKG_CHECK_EXISTS(dbus-glib-1 bluez >= 4.0, > msg_obexftp=yes) > ./gvfs/configure.ac: PKG_CHECK_MODULES(OBEXFTP, dbus-glib-1 bluez >= 4.0) So this basically confines dbus-glib usage to separate daemons (volume monitors and backends), right?
(In reply to comment #1) > Assigning to myself, started working on this. Not entirely true, got pulled out by some other (higher priority) work...
Created attachment 184841 [details] [review] compiling but completely untested patch
The patch above migrates the dbus-glib code in the obexftp backend to GDBus. Unfortunately I haven't been able to test if it works since I haven't got access to a bluetooth enabled device. Nevertheless the code compiles so it could be that I've gotten lucky and it works without changes.
(In reply to comment #6) > The patch above migrates the dbus-glib code in the obexftp backend to GDBus. > Unfortunately I haven't been able to test if it works since I haven't got > access to a bluetooth enabled device. Nevertheless the code compiles so it > could be that I've gotten lucky and it works without changes. I'm afraid you probably wasted your time there. There's a bug opened about rewriting the obexftp code to use the osso-gwobex library directly, thus not using GDBus any more.
> I'm afraid you probably wasted your time there. There's a bug opened about > rewriting the obexftp code to use the osso-gwobex library directly, thus not > using GDBus any more. Oh bummer! Well I atleast got to play with GDBus a bit. :P
What is left of this after the recent merge: http://git.gnome.org/browse/gvfs/commit/?id=fe7e66b5efbc0d2589e326c7ca10fd9451e4e894 ?
ping - can somebody answer comment 9?
The obexftp backend seem to still use dbus-glib. If there's interest I could update https://bugzilla.gnome.org/attachment.cgi?id=184841
(In reply to comment #11) > The obexftp backend seem to still use dbus-glib. If there's interest I could > update https://bugzilla.gnome.org/attachment.cgi?id=184841 Better off rewriting it tbh.
Apart from specific backends, the rest is ported to GDBus now. This includes volume monitors, metadata and core daemon. The only thing left is HAL volume monitor and we're not going to change that, since it's basically unmaintained, only left for compatibility with systems that don't have udisks.
Comment on attachment 184841 [details] [review] compiling but completely untested patch Setting patch status to needs-work as per comments 11 and 12.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/150.