fix: prevent MPRIS D-Bus duplicate name

[ThomasFrans]

Append instance<pid> to the MPRIS bus name to prevent two instances from fighting over the same bus name.

[ThomasFrans]

I noticed that when an ncspot process is running and you open another one, it can't attach itself to the D-Bus bus as each process used the same name. In practice this would mean that when opening a second instance of ncspot when one is already running, my GNOME shell wouldn't display playback controls for the second instance. This could be confusing when the user opens a second instance before they close the first one, in which case the shell won't display any playback controls.

The MPRIS specification solves this by appending a unique identifier to each instances' bus name to prevent duplicate names.

[hrkfdn]

Thanks for the PR. Yeah I think I thought about this back then and was worrying this would break user scripts, because they directly refer to the name org.mpris.MediaPlayer2.ncspot. I'm wondering if it makes sense to only append the PID if it's not the first instance, but not sure how other players do this. Do you know? In any case one of those approaches is better than the current one.

[ThomasFrans]

Firefox uses the PID of the tab that contains the player and appends it like this PR does. Other players might force there to be only one instance per session (like Amberol for example). When you try to start a second Amberol instance, it just brings the original one to the foreground.

Technically ncspot is still unstable as it's major version number is still 0. I know it's important not to break the user experience, but relying on D-Bus names to stay consistent is not really a good idea, especially since the MPRIS specification was only meant to discover players, not make sure they have a consistent name across versions.

I think in general, it might start to make sense to release version 1.0.0 soon if breaking changes are a consideration. The semantic versioning specification also says that when you're thinking about breaking changes, your program should have already been on version 1.0.0 😄

I don't know whether ncspot really follows semantic versioning, but I don't know why it wouldn't as it is one of the versioning schemes that conveys the most information to the user through just 3 numbers, and the current version string already resembles the semantic versioning one. I believe that the Rust community in general also uses semantic versioning most of the time (hence the default version string provided by cargo when a package is created) 🙂

[hrkfdn]

Sounds reasonable, let's get it in then! :)

[hrkfdn]

Also regarding a 1.0 release: I thought about this recently and I guess ncspot - while it has some bugs regarding session refreshment - is mature enough to deserve a major release.

[ThomasFrans]

Even though it has bugs, you can still release version 1.0.0. The bugs will only increase the patch version anyway. It just shows users that you're thinking about breaking changes from now on. As you were already doing this, you might as well let your user know 🙂