Integrated VLC media player controls from separate unrelated software via MPRIS and dbus, one example

[eerkatoka]

As far as I know, this is the only software unrelated to video or audio play - in this case a video game - that has built-in controls for VLC media player, by using MPRIS and dbus. It can do 2 simple things only: pause / play and 4 second skip-back. Any more functionality would reserve precious keys from the video game. This system makes it easier to simultaneously listen audio with complicated subjects while using different unrelated software ( here, playing a video game ):

https://github.com/miheslkivi/pac-person-freespace

It concatenates one of 3 text strings from "/filesforbin/oma.ini" after the system command "qdbus". Is this right? Do the strings have to contain "vlc" in them and be so complicated? One problem with that seems to be that the qdbus command may not be in every Linux. Also, after starting the programs, sometimes 2 key presses are needed for play/pause to take effect. Better use of inter process communication protocols might help? Also, what happens when there are multiple instances / processes?

We have every reason to hope that more unrelated software will start to use simple integrated media player controls like this PPFCU game is doing. There should be wiki page(s) dedicated for helping that.

[FeRDNYC]

(Disclaimer: I don't profess to be any sort of DBus expert, so take what I say with a grain of salt. I probably have some details wrong, I'll be the first to admit. But hopefully not anything major.)

As far as I know, this is the only software unrelated to video or audio play - in this case a video game - that has built-in controls for VLC media player, by using MPRIS and dbus.

I suppose that depends how you define "unrelated". And how you define "software", as well. There are a lot of add-ons for environments like Gnome Shell (and I believe at least Firefox, as well, or there used to be before they banished native extensions) that provide media player controls in various contexts. But I haven't seen that much of it in non-related application software, agreed.

It concatenates one of 3 text strings from "/filesforbin/oma.ini" after the system command "qdbus". Is this right? Do the strings have to contain "vlc" in them and be so complicated? One problem with that seems to be that the qdbus command may not be in every Linux. Also, after starting the programs, sometimes 2 key presses are needed for play/pause to take effect. Better use of inter process communication protocols might help? Also, what happens when there are multiple instances / processes?

Again, whether it's "right" depends on your definition. It's one way to do it. Not the cleanest way, honestly, but the most quick-and-dirty way to easily integrate DBus communication into the software. The strings do have to be that complicated, because DBus is namespaced. They do have to contain VLC, for the same reason. There's no way to communicate with a process on the session bus except by knowing the full servicename and object path of the method you want to call. There's no way for an application to export any object methods on any service other than the one it owns, and there are no "generic" objects in DBus.* Every object is owned by some well-defined service sitting on the bus.

The reason the current implementation appears so messy, though, is because... well, it is. The code uses system() to call the qdbus command whenever it wants to send a command. Like I said, that "works", but a better and cleaner way to do it would be to link the program with the DBus APIs and have it communicate on the session bus directly, rather than calling external commands via system().

That would also likely make the communication more robust, and make it possible to address issues like the one you mentioned about needing to trigger a command more than once. In effect, the software currently isn't "using" the DBus protocol at all, it's blindly tossing messages onto the bus. But it's not communicating in any robust fashion, and it can't receive any responses so it just has to blindly assume that all went well. It could communicate robustly, but that would mean writing code against the DBus API (or Qt's version of it) and linking in libQT5DBus, which requires significantly more development effort than firing off a few system(qdbus) instances. That's all stuff that would be addressed within the game software, though — it's not anything that could be or needs to be addressed on the VLC end.

You're right that qdbus won't be present on every Linux system, but the software in question is a Qt application and qdbus is the Qt command-line tool for DBus communication. So it's not unreasonable to require that qdbus be available anywhere the software is run, since Qt is already a requirement. I'm not sure the pac-person-freespace/pacp.pro project file is actually set up to enforce that requirement, currently, but it could be.

* - The strict namespacing even bit the Gnome developers at one point, who had the DBus service for media keys — play/pause/stop etc. buttons on keyboards — sitting at the wrong DBus name. Nobody noticed that the service where the API was implemented (org.gnome.SettingsDaemon) didn't match the documented service name (org.gnome.SettingsDaemon.MediaKeys), and all software that needed to deal with media key presses just used the "wrong" name. Didn't matter, at the time, because gnome-settings-daemon was handling media keys. When the Gnome Shell developers wanted to take over media key handling, they realized that they couldn't have Gnome Shell listen on org.gnome.SettingsDaemon, because gnome-settings-daemon already was. So they had to make everyone move over to the org.gnome.SettingsDaemon.MediaKeys service name that should've been used all along. (The email about that change.)