Created attachment 170617 [details] [review]
Initial ApplicationInstance and RemoteServiceManager work

Initial pass at the refactor. This gets most things working, but a few items still fail to be registered due to them inheriting from existing classes. Follow-up patch fixes this issue.

With this change, single instance works, and some remote control from the command line works (e.g. queue-ing a new file by doing "Banshee.exe C:\Media\foo.mp3")

Created attachment 170618 [details] [review]
Follow-up to implement more 'remote control' functionality.

This gets the rest of the expected remote objects working by adding an IDBusExportableProvider interface:

interface IDBusExportableProvider
{
     IEnumerable<IDBuxExportable> Exportables { get; }
}

And implementing it for the IClientWindow and IGlobalUIActions remote interfaces, since those currently inherit from existing base classes, instead of MarshalByRefObject.

Additionally, in order for the remote control to work with .NET remoting, it is no longer possible to duplicate the interface definitin from the Halie 'remote control client', since .NET remoting actually checks the specific type matches the remoted type. I've added a reference to Banshee.ThickClient now, and only specifically imported the interfaces in question... The alternative would be a new Banshee.ThickClient.Shared or somesuch... probably not worth another assembly just for this.

With this patch, the full 'remote control' client works, passing in --show, or --show-about, etc, etc.

Thoughts?

Great stuff! (You should get Flattr and blog about this so you can get some cash for beers :)

My 2cents-review:

-    <ProductVersion>8.0.50727</ProductVersion>
+    <ProductVersion>9.0.21022</ProductVersion>

I wouldn't include these bits in the commit, although it's not a big deal. Not sure what version of VS the devs want to target...


+#if WIN32
+            instance = new IpcRemotingApplicationInstance ();
+#else
+			instance = new DBusApplicationInstance ();
+#endif // WIN32

+#if WIN32
+            manager = new IpcRemoteServiceManager ();
+#else
+			manager = new DBusRemoteServiceManager ();
+#endif // WIN32

In these 2 cases, I would advocate for using a new define, for example ENABLE_DBUS and connect it to the option --disable-dbus on the configure phase. This way the Remoting code path can also be enabled in Linux if needed, and I advocate ENABLE_DBUS as opposed to DISABLE_DBUS so Win32 builds are easier to trigger (I'm assuming most Linux devs would use the command line, for which ENABLE_DBUS would be enabled by default, but not VS devs).

But in this case I would maintain WIN32, or in the same vein as above, maybe UNIX?:

+        public static string ApplicationPath {
+            get
+            {
+#if WIN32
+                // TODO: Full installation path using registry key.
+                return "Banshee.exe";
+#else
+                return "banshee-1";
+#endif // WIN32

As far as the version updates... that is required when using VS 2008, which is the minimum needed to compile this stuff... Can we instead just verify that MD plays nicely with that change, and include it? Otherwise continued work on Windows means constantly reverting that one line change before doing commits, it's likely to sneak in accidentally, etc.

I had thought previously that the IPC channels only worked on Windows (via named pipes), but I looked just now on github, and it seems Mono does have support for them. I will switch this to using an ENABLE_DBUS define.

As far as WIN32 vs UNIX for the check, it's fairly straight forward to add the define in the project files for the Windows target, I'd prefer to use the WIN32 define, as it is already used elsewhere in the code.

(In reply to comment #4)
> As far as the version updates... that is required when using VS 2008, which is
> the minimum needed to compile this stuff... Can we instead just verify that MD
> plays nicely with that change, and include it? Otherwise continued work on
> Windows means constantly reverting that one line change before doing commits,
> it's likely to sneak in accidentally, etc.

/me nods
Wasn't opposed to it, but the perfectionist inside me would push that in a different commit :)

> I had thought previously that the IPC channels only worked on Windows (via
> named pipes), but I looked just now on github, and it seems Mono does have
> support for them. I will switch this to using an ENABLE_DBUS define.

Cool.

> As far as WIN32 vs UNIX for the check, it's fairly straight forward to add the
> define in the project files for the Windows target, I'd prefer to use the WIN32
> define, as it is already used elsewhere in the code.

True. But now that I think about it, I think it's always desirable to avoid defines as much as possible if it can be replaced by a runtime check (this way the assemblies are more similar regardless the platform). I normally see defines useful when a certain portion of the code can only work if the assembly is linked to an assembly that is used/existant only in that platform. But, as the first part of this comment, this is just a nitpick for perfectionists ;) I'm not by any means the maintainer that should review this patch.

It seems MonoDevelop is happy with the <ProductVersion>9.0.21022... thing

It keeps it as is when you edit the project options, and newly created projects even have it by default.

So I think we can change those piece by piece, until someone is bored enough to do it for all .csproj files ;)

Hey Peter, looks pretty nice!  Change the file headers to be Copyright you.  RemoteClientWindow.cs has the wrong filename in its header.

Gabriel: I will double check all the new files are copyright me, and verify the filenames in the headers. I will not change the copyright to me for files I have just changed, though. Unless you meant those as well?

Created attachment 170788 [details] [review]
Updated version, as one patch now.

Ok, lots of fixes/changes since last time:

1) Fixed copyright header info.
2) Made this whole ball of wax actually compile and run properly on Linux (tested on Ubuntu here). Key points:
    a) Fix the makefiles/build stuff,
    b) NDesk.DBus does bad, bad things to objects that subclass MarshalByRefObject, attempting to export their entire public API, instead of only exporting the types explicitly marked with the NDesk.DBus.InterfaceAttribute attribute. A hacky solution, until a proper fix in ndesk-dbus (or dbus-sharp?) can be found is to only conditionally make the classes inherit from MarshalByRefObject.
3) Used ENABLE_DBUS instead of WIN32 for determination of DBus vs .NET Remoting.
4) For now, hardcoded the ENABLE_DBUS when building with the makefiles (versus via VS solution files) (In thinking about it, the VS/MD files will probably need to have the ENABLE_DBUS define added for the profiles other than the Windows one)

Great.

(In reply to comment #9)
> Created an attachment (id=170788) [details] [review]
> Updated version, as one patch now.
> 
> Ok, lots of fixes/changes since last time:
> 
> 1) Fixed copyright header info.
> 2) Made this whole ball of wax actually compile and run properly on Linux
> (tested on Ubuntu here). Key points:
>     a) Fix the makefiles/build stuff,
>     b) NDesk.DBus does bad, bad things to objects that subclass
> MarshalByRefObject, attempting to export their entire public API, instead of
> only exporting the types explicitly marked with the
> NDesk.DBus.InterfaceAttribute attribute. A hacky solution, until a proper fix

If it's a hack, I would advocate for, at least, filing a bug in dbus-sharp, and add a comment with the URL of the bug in every instance of the hack.

> in ndesk-dbus (or dbus-sharp?) can be found is to only conditionally make the
> classes inherit from MarshalByRefObject.
> 3) Used ENABLE_DBUS instead of WIN32 for determination of DBus vs .NET
> Remoting.
> 4) For now, hardcoded the ENABLE_DBUS when building with the makefiles (versus
> via VS solution files) (In thinking about it, the VS/MD files will probably
> need to have the ENABLE_DBUS define added for the profiles other than the
> Windows one)

Did you really test that with this, single instance detection is still working when using --disable-dbus ?

Andres: Unfortunately we can't switch those at runtime *yet*, until the NDesk.DBus bug gets resolved. As is, we need to conditionally have our remoted types subclass MarshalByRefObject at compile time in order to have one or the other 'modes' work. ):

I can try to find time to add a fix/workaround for the NDesk.DBus issue, but in the meantime, the compile-time choice has to stay.

Created attachment 171047 [details] [review]
Updated version, fix conflict in one .csproj file

An updated version that just fixes a conflict from one .csproj file that was changed by my other patch to add 'network status' support on windows.

Review of attachment 171047 [details] [review]:

You have some properties that don't follow the style guideline (they have their { on its own line).

Application.ApplicationPath should probably be named ExecutableName or something, no?

Looks like most if not all the new files' copyright headers have Copyright Novell still.

Can you only compile the System.Runtime.Remoting-dependent code if !DBUS_ENABLED, or perhaps only if explicitly asked for?

private string getServiceName method should start w/ a capital letter

In ServiceManager.cs can remove the line instead of commenting it out.

Why do we have to have RemoteGlobalUIActions etc classes now, where before we just had the GlobalUIActions etc classes themselves say they were IDbusExportable and that was it, right?

[GB] Application.ApplicationPath should probably be named ExecutableName or
something, no?

I will rename.

[GB] Looks like most if not all the new files' copyright headers have Copyright
Novell still.

D'oh. Will fix that in my next patch.

[GB] Can you only compile the System.Runtime.Remoting-dependent code if
!DBUS_ENABLED, or perhaps only if explicitly asked for?

Yes, I can do that. Eventualy (probably once we move to dbus-sharp and I have a chance to put in some fixes/new API there) I would like to have it be a runtime selection instead of compile time.

[GB] Why do we have to have RemoteGlobalUIActions etc classes now, where before we
just had the GlobalUIActions etc classes themselves say they were
IDbusExportable and that was it, right?

The issue is the existing GlobalUIActions and the various implementations of IClientWindow have existing base classes, that cannot (nor should, IMHO) be easily changed. In order to be properly remoted via .NET remoting, the base class must be MarshalByRefObject. RemoteGlobalUIActions and RemoteClientWindow are just 'proxy classes' for any non-remotable implementation of the associated interface. I'm open to other solutions to that particular problem though.

Created attachment 171453 [details] [review]
Updated patch to address reported issues.

Could we generate the proxy classes dynamically?  dbus-sharp does that in some cases, I believe.

We certainly could. Any objections to using Castle DynamicProxy (http://www.castleproject.org/dynamicproxy/index.html) to do so, in order to avoid having to include tons of nasty System.Reflection.Emit in Banshee?

(In reply to comment #11)
> Andres: Unfortunately we can't switch those at runtime *yet*, until the
> NDesk.DBus bug gets resolved. As is, we need to conditionally have our remoted
> types subclass MarshalByRefObject at compile time in order to have one or the
> other 'modes' work. ):
> 
> I can try to find time to add a fix/workaround for the NDesk.DBus issue, but in
> the meantime, the compile-time choice has to stay.

Isn't the generation of proxy classes dynamically kind of a big effort compared to maybe fix the dbus-sharp bug? Anyway I think a bug against dbus-sharp/ndeskdbus should be filed and write the URL of it in the patch. So people know why this hassle is done and, at some point when the bug is fixed, remove the cruft.

Created attachment 172065 [details] [review]
Fix to NDesk.DBus to allow ignoring MarshalByRefObject base class

This is the necessary patch to NDesk.DBus needed for the next version of the Banshee changes. It adds a new attribute, IgnoreMarshalByRefObjectBaseClassAttribute that can be used to get NDesk.DBus to ignore the class when decided what API to export.

Created attachment 172067 [details] [review]
Updated version, now selects implementation at runtime.

Updated version that selects the implementation to use at runtime.

Pete, you said you'd change a few things that are still called DBus* needlessly, right?

Created attachment 175141 [details] [review]
Updated version, with IDBusXXX renamed

Ok, updated patch that includes renaming the IDBusXXX interfaces to IRemoteXXX instead, to better reflect their independence from the DBus specifics.

Still depends on the fix/patch to NDesk.DBus/dbus-sharp. Will work on getting that merged upstream.

*** Bug 641731 has been marked as a duplicate of this bug. ***

*** Bug 643230 has been marked as a duplicate of this bug. ***

*** Bug 643387 has been marked as a duplicate of this bug. ***

Hey Pete, is your patch in dbus-sharp now?  I'm wondering if maybe we should merge the dbus-sharp branch into banshee master for the Windows builds only.

Gabriel,

It is not. I updated the dbus-sharp branch a while ago with the intention of rebasing my work on that branch, but have not had an opportunity to actually do that rebasing yet. It shouldn't be much work, I will try to find time to do that sometime this week.

Created attachment 182154 [details] [review]
Updated patch against dbus-sharp branch

I've merge up the dbus-sharp branch on git.banshee.org with the latest from master, and rebased my work on the dbus-sharp branch.

To test on Windows, you'll need to first copy the dbus-sharp.dll and dbus-sharp-glib.dll from Linux into the windows-binaries checkout in bin\bin\.

Peter, are we missing anything in upstream dbus-sharp?  Looks like your pull request in github got merged a couple of weeks ago:

https://github.com/mono/dbus-sharp/pull/11#issuecomment-754563

Sandy,

Nope. dbus-sharp is fine. The only real blocker is waiting on the dbus-sharp branch to be merged to mainline (which, AFAIK, is waiting on dbus-sharp to be packaged for various distros)

Created attachment 183259 [details] [review]
Updated version, addresses GUI access issues

Ok, here's an updated patch. Still against the dbus-sharp branch.

This version improves the .NET remoting support by ensuring the primary GDK lock is held when invoking all the remote calls.

*** Bug 647213 has been marked as a duplicate of this bug. ***

*** Bug 650926 has been marked as a duplicate of this bug. ***

Comment on attachment 183259 [details] [review]
Updated version, addresses GUI access issues

Quick review:

- This patch needs to be updated to apply cleanly to master.
- Pete's patch to dbus-sharp was merged, and the first version of dbus-sharp to ship this is the recently released (2 days ago) 0.8. This means that the patch needs to include a change on the configure phase to raise the dependency version number of dbus-sharp.
- The patch is still using the old name "IgnoreMarshalByRefObjectBaseClass", when it was decided to be named "ExportInterfaceMembersOnly" upstream: https://github.com/mono/dbus-sharp/commit/0536ba9848d9655504b127b5dc5f76fb93412146

This code:
+            ServiceNameOwner owner = null;
+            try {
+                owner = FindInstance<ServiceNameOwner> (serviceName, "/ServiceNameOwner");
+
+                return owner != null && owner.Ping ();
+            } catch (RemotingException) {
+                return false;
+            } finally {
+                if (owner != null) {
+                    try {
+                        ((IDisposable)owner).Dispose ();
+                    } catch { }
+                }
+            }

Can be much more simplified converting it to a "using () { }" block AFAIK. There are more cases in the patch like this, not only this one.

And last but not least, I still think this would be better as a runtime check:
+#if WIN32
+                // TODO: Full installation path using registry key.
+                return "Banshee.exe";
+#else
+                return "banshee-1";
+#endif // WIN32

I also noticed this change:

-LINK_DBUS = $(DBUS_SHARP_LIBS) $(DBUS_SHARP_GLIB_LIBS)
+LINK_DBUS = $(DBUS_SHARP_LIBS) $(DBUS_SHARP_GLIB_LIBS) /define:ENABLE_DBUS

Not only this define shouldn't go assigned in a variable called "LINK_foo" (because it's only for references; therefore a _FLAGS one should be used I think), the ENABLE_DBUS define is actually not used anymore in the patch. Why?

I'm porting the patch to git master (it doesn't apply, mainly because of this: https://github.com/GNOME/banshee/commit/b780ebced90e5aae3464e16fb686f25ddd21fd9b) and during this work I've noticed some things that I don't understand from the patch:

1) Why IpcRemotingApplicationInstance.ApplicationInstance is IDisposable if its Dispose() method is empty? (I'm going to remove this if nobody objects.)

2) Why IpcRemotingApplicationInstance.Connect() method does nothing?

Pete, I understand you are kind of less active these days, but would appreciate if you spent 5 mins to answer this :)

Cheers!

We need to apply this patch from Chow before applying the fix for this: http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/banshee.git;a=blob;f=debian/patches/Use-dbus-2.patch;h=9ce676446f8838ad5427f37b3bd17a5867932490;hb=HEAD

(In reply to comment #37)
> We need to apply this patch from Chow before applying the fix for this:
> http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/banshee.git;a=blob;f=debian/patches/Use-dbus-2.patch;h=9ce676446f8838ad5427f37b3bd17a5867932490;hb=HEAD

I already have a patch somewhere for this, which does a bit more changes to remove some cruft in DBusServiceManager.

I'll commit it shortly, if that's OK.

(In reply to comment #38)
> (In reply to comment #37)
> > We need to apply this patch from Chow before applying the fix for this:
> > http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/banshee.git;a=blob;f=debian/patches/Use-dbus-2.patch;h=9ce676446f8838ad5427f37b3bd17a5867932490;hb=HEAD
> 
> I already have a patch somewhere for this, which does a bit more changes to
> remove some cruft in DBusServiceManager.

Ah cool! BTW have a look at my recent commits in master, I also simplified some things around DBus.


> I'll commit it shortly, if that's OK.

I was thinking that we should only commit the migration to Dbus2 if we're going to commit the patch for this bug shortly after. And given that it's taking me a bit more time to port this patch to master, I'm leaning towards leaving this to after release 2.9.1, what do you think?

(I only want to commit 1 more thing, related to Gapless+GStreamerSharp into master to be 100% happy for a 2.9.1 release. Then we could work on this and GSettings for 2.9.2. What do you think?)

(In reply to comment #39)
> > I'll commit it shortly, if that's OK.

If you don't mind, can you post here the patch first? I ask because today I found that Chow's patch doesn't work (it compiles, but it fails with the exception below when you try to run a 2nd banshee instance), so I wanted to test yours:

Unhandled Exception:
System.ArgumentException: Cannot create a struct with no fields
Parameter name: signature
  at DBus.Protocol.Signature.MakeStruct (Signature signature) [0x00000] in <filename unknown>:0 
  at DBus.Protocol.Signature.GetSig (System.Type type) [0x00000] in <filename unknown>:0 
  at DBus.TypeImplementer.SigsForMethod (System.Reflection.MethodInfo mi, DBus.Protocol.Signature& inSig, DBus.Protocol.Signature& outSig) [0x00000] in <filename unknown>:0 
  at DBus.TypeImplementer.GenHookupMethod (System.Reflection.Emit.ILGenerator ilg, System.Reflection.MethodInfo declMethod, System.Reflection.MethodInfo invokeMethod, System.String interface, System.String member) [0x00000] in <filename unknown>:0 
  at DBus.TypeImplementer.Implement (System.Reflection.Emit.TypeBuilder typeB, System.Type iface, System.String interfaceName) [0x00000] in <filename unknown>:0 
  at DBus.TypeImplementer.GetImplementation (System.Type declType) [0x00000] in <filename unknown>:0 
  at DBus.BusObject.GetObject (DBus.Connection conn, System.String bus_name, DBus.ObjectPath object_path, System.Type declType) [0x00000] in <filename unknown>:0 
  at DBus.Connection.GetObject (System.Type type, System.String bus_name, DBus.ObjectPath path) [0x00000] in <filename unknown>:0 
  at DBus.Connection.GetObject[IPlayerEngineService] (System.String bus_name, DBus.ObjectPath path) [0x00000] in <filename unknown>:0 
  at Banshee.ServiceStack.DBusServiceManager.FindInstance[IPlayerEngineService] (System.String serviceName, Boolean isFullBusName, System.String objectPath) [0x00000] in <filename unknown>:0 
  at Banshee.ServiceStack.DBusServiceManager.FindInstance[IPlayerEngineService] (System.String objectPath) [0x00000] in <filename unknown>:0 
  at Halie.Client.HandlePlayerCommands () [0x00000] in <filename unknown>:0 
  at Halie.Client.Main () [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.AppDomain:ExecuteAssembly (System.AppDomain,System.Reflection.Assembly,string[])
  at System.AppDomain.ExecuteAssemblyInternal (System.Reflection.Assembly a, System.String[] args) [0x00000] in <filename unknown>:0 
  at System.AppDomain.ExecuteAssembly (System.String assemblyFile, System.Security.Policy.Evidence assemblySecurity, System.String[] args) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.AppDomain:ExecuteAssembly (string,System.Security.Policy.Evidence,string[])
  at System.AppDomain.ExecuteAssembly (System.String assemblyFile) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.AppDomain:ExecuteAssembly (string)
  at Booter.Booter.BootClient (System.String clientName) [0x00000] in <filename unknown>:0 
  at Booter.Booter.Main () [0x00000] in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentException: Cannot create a struct with no fields
Parameter name: signature
  at DBus.Protocol.Signature.MakeStruct (Signature signature) [0x00000] in <filename unknown>:0 
  at DBus.Protocol.Signature.GetSig (System.Type type) [0x00000] in <filename unknown>:0 
  at DBus.TypeImplementer.SigsForMethod (System.Reflection.MethodInfo mi, DBus.Protocol.Signature& inSig, DBus.Protocol.Signature& outSig) [0x00000] in <filename unknown>:0 
  at DBus.TypeImplementer.GenHookupMethod (System.Reflection.Emit.ILGenerator ilg, System.Reflection.MethodInfo declMethod, System.Reflection.MethodInfo invokeMethod, System.String interface, System.String member) [0x00000] in <filename unknown>:0 
  at DBus.TypeImplementer.Implement (System.Reflection.Emit.TypeBuilder typeB, System.Type iface, System.String interfaceName) [0x00000] in <filename unknown>:0 
  at DBus.TypeImplementer.GetImplementation (System.Type declType) [0x00000] in <filename unknown>:0 
  at DBus.BusObject.GetObject (DBus.Connection conn, System.String bus_name, DBus.ObjectPath object_path, System.Type declType) [0x00000] in <filename unknown>:0 
  at DBus.Connection.GetObject (System.Type type, System.String bus_name, DBus.ObjectPath path) [0x00000] in <filename unknown>:0 
  at DBus.Connection.GetObject[IPlayerEngineService] (System.String bus_name, DBus.ObjectPath path) [0x00000] in <filename unknown>:0 
  at Banshee.ServiceStack.DBusServiceManager.FindInstance[IPlayerEngineService] (System.String serviceName, Boolean isFullBusName, System.String objectPath) [0x00000] in <filename unknown>:0 
  at Banshee.ServiceStack.DBusServiceManager.FindInstance[IPlayerEngineService] (System.String objectPath) [0x00000] in <filename unknown>:0 
  at Halie.Client.HandlePlayerCommands () [0x00000] in <filename unknown>:0 
  at Halie.Client.Main () [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.AppDomain:ExecuteAssembly (System.AppDomain,System.Reflection.Assembly,string[])
  at System.AppDomain.ExecuteAssemblyInternal (System.Reflection.Assembly a, System.String[] args) [0x00000] in <filename unknown>:0 
  at System.AppDomain.ExecuteAssembly (System.String assemblyFile, System.Security.Policy.Evidence assemblySecurity, System.String[] args) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.AppDomain:ExecuteAssembly (string,System.Security.Policy.Evidence,string[])
  at System.AppDomain.ExecuteAssembly (System.String assemblyFile) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.AppDomain:ExecuteAssembly (string)
  at Booter.Booter.BootClient (System.String clientName) [0x00000] in <filename unknown>:0 
  at Booter.Booter.Main () [0x00000] in <filename unknown>:0

Created attachment 270504 [details] [review]
Patch to require dbus-sharp 0.8, and associated cleanups

Here's the patch I mentioned.
I did a quick test, and I didn't hit the ArgumentException you mention. I also remember doing more extensive tests right before dbus-sharp 0.8 was release, without noticing it.

On the question of whether to commit this before or after the release, I'm fine either way, I guess it would depend on you level of confidence with this change.

(In reply to comment #41)
> Created an attachment (id=270504) [details] [review]
> Patch to require dbus-sharp 0.8, and associated cleanups
> 
> Here's the patch I mentioned.

Thanks, I think this is a much better patch.


> On the question of whether to commit this before or after the release, I'm fine
> either way, I guess it would depend on you level of confidence with this
> change.

I've given this some thought and I think I prefer to introduce this change after we release 2.9.1.

Comment on attachment 270504 [details] [review]
Patch to require dbus-sharp 0.8, and associated cleanups

(In reply to comment #41)
> Created an attachment (id=270504) [details] [review]
> Patch to require dbus-sharp 0.8, and associated cleanups

Just one thing missing in this patch:
- banshee-collection-indexer.pc.in: dbus-sharp-2.0 instead of dbus-sharp-1.0
- build/pkg-config/banshee-core.pc.in: same as above, plus dbus-sharp-glib-2.0 instead of dbus-sharp-glib-1.0

Marking as needs-work so we don't forget this bit before committing it.

(In reply to comment #43)
> ...

I've also tested this patch with d-feet (to instruct banshee to start playing, for example, on the PlayerEngine interface), and I got this error:

'GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name :1.128 was not provided by any .service files'

Any idea of why is this? We should also probably move this conversation to bug 725446 because this is unrelated to single-instance in Win32.

(In reply to comment #43)
> Marking as needs-work so we don't forget this bit before committing it.

FYI I've updated your patch to include the .pc.in file changes, and posted it to bug 725446.

Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.