GNOME Bugzilla – Bug 629844
Make Banshee uses dbus-sharp instead of NDesk-Dbus
Last modified: 2011-04-29 04:50:32 UTC
Created attachment 170415 [details] [review] Proposed patch Change the build system and update namespaces in source files to use dbus-sharp library instead of ndesk-dbus.
Nitpick in the patch: - // but NDesk DBus has a design flaw where it only exports + // but DBus has a design flaw where it only exports I believe this should read "DBus-sharp" not just DBus, or people may think that the flaw is in the IPC mechanism ;)
Thanks for working on this! dbus-sharp is not yet packaged on (m)any distributions so at this point I'm not sure replacing NDesk.DBus with it is a sound approach. May be we should check if dbus-sharp is available and fall back to NDesk.DBus if it's not?
Another thing that would need to be updated are all the references in the .csproj files. Fun, I know... Because of that and all the namespace changes that are necessary : -using NDesk.DBus; +using DBus; I think supporting both would be possible but tedious, and possibly painful for third-party extension. Maybe this could live on a branch on git.gnome.org, and would get merged when dbus-sharp is more widespread and has had a stable release.
Review of attachment 170415 [details] [review]: Committed to a newly created `dbus-sharp` branch. I also fixed .csproj and .pc references in that branch. I'm leaving this bug open until the branch is merged into master. Please base all future dbus-sharp related patches off this branch.
Is the dbus-sharp discussed here the same as the old one? Years ago we replaced dbus-sharp with NDesk.DBus. Is dbus-sharp a binding to libdbus? There were a lot of good advantages to using NDesk.DBus at the time. What's the reason for wanting to change/go back to the dbus-sharp binding?
Nevermind - it seems that we're talking about this: https://github.com/mono/dbus-sharp Which looks to be NDesk.DBus renamed to DBus/dbus-sharp (which is mildly confusing to old farts like me). I'm in favor of this, but don't really see the point of applying the patch until it's widespread in the distros. Alternatively, we could do something like this: #ifndef NEW_DBUS using DBus = NDesk.DBus; #endif using DBus; Though I of course hate the compilation conditionals...
Yes, since the original dbus-sharp was deemed forgotten enough we kinda re-used the name as is. It's actually a fork of NDesk.DBus which at the moment isn't really diverging from the last release except it includes longstanding bug fixes and improvements that had accumulated over the years. The plan is actually to continue working on this at the GNOME+Mono hackfest that is coming during/after FOSDEM. I personally have a cleanup branch that I wish to finish there.
I've merged up the dbus-sharp branch with the latest mainline and pushed, and confirmed it still builds and runs fine with the current dbus-sharp/dbus-sharp-glib.
From my perspective, the key issue for me is the new API/change I need in NDesk.DBus/dbus-sharp to make my ".NET remoting on windows" work possible (see bug #630110). Since upstream NDesk.DBus is dead, the only real way for me to move forward is to have the dbus-sharp finished (I'll be updating that branch to be based on the dbus-sharp branch soon).
Reopening as the question raised in comment 6 has been answered.
dbus-sharp branch merged into master