Starting work on version 2.0.0

[GuardKenzie]

Hi all!

This has been quite a while in the making (ever since Überzug went offline) but I am finally getting started on development for v2.0.0. This announcement is supposed to serve as reassurance that this project has, in fact, not been abandoned and to invite suggestions/requests for the new version from anyone out there interested in this project.

Terminal graphics

These past months I have been working on a project called chafa.py. It is Python bindings for the amazing terminal image visualizer Chafa by @hpjansson. This allows miniplayer to implement modern terminal graphics through the Kitty, iTerm2 and Sixel protocols and to fall back on really good text-based approximations for terminals that support none of these. All this is achieved with minimal dependencies (only Pillow for loading image data).

Urwid

Another major change will be moving from curses to Urwid as a display backend. Curses is old and surprisingly limited when it comes to stuff like displaying graphics with these modern protocols. I did take a look at notcurses but I don't feel like it is a viable candidate due to lack of documentation for the Python bindings. This will also solve issue #34.

Structural changes

There will be a lot of refactoring going on. I originally built this as a simple, throw-together applet for me to use personally and this is reflected in the project structure. I will try to write a more robust backend to interface with python-mpd2 and since Urwid is going to take care of a lot of they layout work, this should result in much more readable code.

What I'm keeping

There is a lot of things that I like about the project at the moment so here is a list of the major things that will stay the same in v2:

• The UI and the responsive layout
• The command line (but hopefully with improved funcitonality)
• The config backend (this is mostly because configparser comes bundled with Python)
• Configurable colors and keybinds
• Dynamic colors

What is going away

There's not a lot of stuff that will be going but here's a list:

• Album art only mode
• Album art fetching from HTTP server #17 (I will try to implement this but I might need some help from you @bartkl) EDIT: this point was moved to going away as per discussion below

Developement

If you are interested, you can follow the progress on the new v2-dev branch.

I'll keep you posted,
Erica
🧡

[bartkl]

Hi Erica,

That's exciting news! And I'm happy to help out where I can.

With regards to the HTTP server for the album art: I'm no longer in need of it. For quite some time now, the MPD protocol supports serving album art natively through the albumart command, and all MPD clients I use (myMPD and MAFA) support that.

Since the HTTP server solution is quite frail and complex, and at least I'm no longer using it, you may want to reconsider whether you want to support it. Perhaps you can post a poll here to inquire if others use it?

Thanks for the great work, I'm excited to see where this goes 😄.

Kind regards and greetings from the Netherlands,
Bart

[GuardKenzie]

Happy to hear it!

With regards to the HTTP server for album art: I'm no longer in need for it. For quite some time now, the MPD protocol supports serving album art natively through the albumart command, and all MPD clients I use (myMPD and MAFA) support that.

Of course! I totally forgot that's a thing. This was even implemented with #29 thanks to @aaw3 but just as a fallback. It will probably become the main way for extracting album art moving forward, eliminating yet another dependency (ffmpeg in this case).

Also, since this eliminates the need for the HTTP server, it will be removed with v2. Thanks for the input 🧡