Would there be appetite for a TUI frontend?

[erikvanhamme]

I am looking for a TUI music player that can do gap-less playback. None of the TUI music players really do what I want. I love the playback engine of audacious. Audacious can already be switched between Qt and GTK2/3 at build time.

Does it make sense for me to pursue building a TUI frontend for Audacious? I'd be willing to do the work myself, but I wanted to gauge if there would be any chance that a PR would get accepted.

Some background: I am an embedded firmware engineer with 20 years of experience in embedded C/C++. I am confident in my programming abilities. What would be new for me is the meson build system and some of the intricacies of dependency management on Linux. I imagine the learning curve would be manageable.

This would be a slow-burn project. I don't have all that much free time.

My main goals would be:

1. Can run from TTY, or inside kitty.
2. Support play/enqueue of a set of files from yazi file manager.
3. Rescalable TUI interface that grows/shrinks with the terminal size.
4. Possible to build without Qt or GTK dependencies.

My questions:

1. Is this feasible at all?
2. Would this be appreciated by the devs? Does anyone of the current project team want this? Any chance of a PR getting accepted?
3. Is there someone who wouldn't mind answering some beginner questions about the codebase? No doubt some will crop up should I start.

In any case thanks for the music player development. Even though I can't use it in the terminal, it's still a fantastic player.

Best regards, Erik

[mschwendt]

Have you played with "headless" Audacious yet? i.e. "audacious -H" CLI mode with/without "audtool" to control it.

[erikvanhamme]

Thanks for mentioning that. Much appreciated.

I was unaware Audacious could do that. Perhaps the more sane approach would be to write my TUI frontend using libaudclient and control an unaltered Audacious process through dbus.

The last commit to libaudclient was 12 years ago. Does this mean the dbus interface is incredibly stable? Or is libaudclient abandoned?

[radioactiveman]

libaudclient was the previous implementation for D-Bus support, based on dbus-glib. It has been removed with Audacious 3.5.

The current approach uses the more modern GDBus. You can find the specification in /audacious/src/dbus/aud-dbus.xml. Based on it, aud-dbus.c / aud-dbus.h are auto-generated at build time. audtool also makes use of this, you can see my commit to better understand how the D-Bus functions can be called in code.

Regarding stability the D-Bus methods / signatures didn't really change in recent years.

[radioactiveman]

@jlindgren90: What do you think about a TUI interface? Are you interested in this idea to offer a better, more advanced headless-mode?

@erikvanhamme: I would be open to support with answering beginner questions related to Audacious and Meson.
But I have no experience yet with implementing a TUI interface and potential libraries like ncurses. So most of the work should be on your side.

What TUI music players have you tried yet? And which one would you recommend to better understand how an Audacious interface could look and feel like?

[jlindgren90]

I think it's a great idea.

Two options: (1) implement it as a UI plugin. Start with one of the existing UI plugins and just rip out all the GTK or Qt stuff. (2) Implement an out-of-process TUI and talk to Audacious over MPRIS2. There is some prior art (quick search turns up https://github.com/qxb3/fum) so you could start with something like that and modify/expand it.

I would suggest to use MPRIS2 rather than the bespoke D-Bus API that audtool uses, because it's standardized - your UI will work with other players as well.

[erikvanhamme]

Sorry for being incommunicado for a while. Life got in the way.

I have not decided yet if I will use MPRIS2 or completely embed the TUI. I think MPRIS2 will be easier, but full embedding would be my preference. I think the performance will be better, and then I would be able to compile without any Qt or GTK dependencies on my system. Additionally, then I can leverage the fact that audacious can be started multiple times with one instance adding items to the playlist of another instance.

Another consideration I have: If I go for MPRIS2, I will immediately be exposed to the quirks of all other audio players that could be used with it as well. This could make the problem domain larger. I think long term it would be easier to just deal with audacious.

As I will need the TUI in any case, I am focusing on learning that first. I don't have to decide this right now. I will come back to this discussion if I have a mockup of how it could look. If I have something to show, it will be easier for you maintainers as well to decide if you want it in the codebase or not.

Best regards, Erik

[wildstar84]

Audacious is such a good, complete, all-arround player that if I could think of just ONE thing that'd make it complete/zen it would be an ncurses? / termininal / text-based interface option (at least a playlist table screen). I looked at it a good while back and, having never done anything w/ncurses, my eyes just glazed over (didn't persue it further). I agree w/OP, it's an interesting concept!