Project

General

Profile

Forums » Audacious »

New remote control solution / successor for libaudclient functions?

Added by Thomas Hoffmann over 9 years ago

As you phased out the audacious_remote_* functions (""libaudclient is no longer included with Audacious because it is tied to the older dbus-glib library. However, existing copies of libaudclient will still work with Audacious 3.5.), I am looking for a successor for these functions.

Is your plan to continue to support libaudclient also for v3.6 and following?
Or are there / will there be remote functions based on the newer GDBus library?


Replies (6)

RE: New remote control solution / successor for libaudclient functions? - Added by John Lindgren over 9 years ago

We're not changing the D-Bus API1, so libaudclient will continue to work fine. If you want to use GDBus instead, the audtool source code should be a good example of how to do it -- on the other hand, if you're going to the trouble of migrating, you might want to consider using the MPRIS 2 API2 instead of the specific Audacious API; then you automatically gain support for several other music players as well.

1 https://github.com/audacious-media-player/audacious/commits/master/src/dbus/aud-dbus.xml

2 http://specifications.freedesktop.org/mpris-spec/latest/

RE: New remote control solution / successor for libaudclient functions? - Added by Thomas Hoffmann over 9 years ago

I looked into the MPRIS2 API but it seems to be "poor" compared to the specific Audacious API: E.g., I did not find a way to get sample rate and number of channel information.
Now I started to migrate (some of) the remote functions from libaudclient to GDBus, which seems to work..

RE: New remote control solution / successor for libaudclient functions? - Added by Thomas Hoffmann over 9 years ago

To follow up myself: when trying to have all the functions of the remote library migrated, I was missing the "ToggleAot" in the new interface description (aud-dbus.xml). Is this intentional?

RE: New remote control solution / successor for libaudclient functions? - Added by John Lindgren over 9 years ago

Yes, ToggleAot has been broken a long time (since version 3.0) in the skinned UI, and never worked with GTKUI.

RE: New remote control solution / successor for libaudclient functions? - Added by Thomas Hoffmann over 9 years ago

I see. So, I have now a "libaudclient-3.6" at hand, based on the GDBus interface. Only remarkable difference is that it uses the generated ObjAudacious as proxy on the client side (instead of a generic proxy type) and so aud-dbus.h has to be provided when compiling client code. I am not sure if this is the preferred way.

Do you think it would make sense to add this code back to audacious?

RE: New remote control solution / successor for libaudclient functions? - Added by John Lindgren over 9 years ago

If we do begin publishing an "official" replacement for libaudclient, I would like it to have an API that doesn't explicitly reference any other library. That way, we won't be stuck with using GDBus permanently, as libaudclient is stuck with using dbus-glib. That said, I don't think there's a need to rush out with a new library just yet. libaudclient continues to work fine for the time being, and with the migration to Qt in progress, we may find some other IPC solution that doesn't have a GLib/GIO dependency.

    (1-6/6)