The future of GNOME Music

GNOME Music is an app that I particularly fell in love. Not because it worked perfectly (it didn’t, at all), nor because it’s fast to the last bit (it isn’t, at all), neither because it’s written in a programming language that I love (i.e. C. And no, it isn’t).

So why the hell did I invest my free time, energy and resources on it? If we look on how it is right now, it makes no sense. So for my dog’s sake, why?

Simply because I want to push GNOME forward.

I saw a very rough, embryonic prototype of what could be a good app. I saw bottlenecks all around, things to fix, tasks to complete. I saw pretty good mockups available. All the ingredients were there, we just needed a little bit of love. Working on challenging apps almost always ends up pushing the entire plataform forward.

To add value to this discussion, and for you guys to understand the future of GNOME Music, we must see the history of this app first.

Long ago…

There was an app called GNOME Music. It was written as a quick prototype in JavaScript. Then, another version of the same app was written in Python, and this snaky version of the app was more complete than the other.

The Python version was made the official one.

And yet, the pythonic Music was also a quick prototype.

I’m not particularly against quick prototypes. It’s just that the methods to maintain prototypes are radically different from the methods to maintain apps on the long run. Prototypes are meant to be rapidly developed and showcase a certain functionality, right? GNOME Music, however, is part of the extended GNOME plataform – this implies maintaining it for thousands of users during many years.

Features were being added to Music in such a way that the code was getting messier and messier. That sucks.

Back to the Future

All this trip to the past has serious implications on how GNOME Music codebase looks like now. At the GNOME Core Apps Hackfest, we had the chance to sit down, analyse the code and sketch out what we need to do.

Sad news: most of this work consists of fixing and reorganizing what we have now, so in the future we can still read Music’s code and work on it (instead of sitting down and crying every time we have to deal with it, which is basically what used to happen a few months ago).

If I’m to draw how Music’s codebase is organized right now, it’d look like this:

current-music
Music codebase as it looks right now

Basically, everything is spread all around the entire codebase. Based on that, here is our current, actionable list of tasks on how to fix that (the names are not final):

  • All the data will be encapsulated by a new backend class
  • A new concept of “data sources” will beintroduced
    • Data source is an interface for code that provides data
    • Data sources provide:
      • Albums
      • Artists
      • Playlists
      • Search results
    • The current sources will implement this interface
      • Grilo will be a data source
      • Tracker will be another data source
  • Only one singleton class will exist, the Backend class
    • The Backend manages:
      • The Playlists object
      • Data sources
      • The Player
      • Album art cache
      • MPRIS
  • The UI only communicates with the backend

tl; dr: we’re splitting UI from backend work and adding a layer to abstract data sources. This is how it should look like, after the plan is implemented:

next-music
Next architecture of GNOME Music

 

We probably may be overloading the Backend class (suggestions?) but this new architecture will give us some more flexibility to implement new data providers, sync online accounts data, and whatever else we need.

I already started working on this move with the Playlists code. You can check it out here. It needs review and, of course, testing, but the prototype is there to show how we can move on.

And the Sun starts to shine again on Music land.


23 responses to “The future of GNOME Music”

  1. Awesome! Looking forward to improvements.

  2. The new code architecture looks much better, indeed.

    I wonder, there are many music players written with GTK+. Is there not a high-level library to build a new music player easily? Because when it comes to the UI of a music player, it seems that everybody has different needs. For example I use Exaile because I prefer to browse my music from the file system directories (following my own classification). A library could provide the backend part, and some basic building blocks for the GUI. The library could be developed either as a toolkit (like GTK+ widgets, self-contained classes), or as a framework (the library provides the main object-oriented architecture that all music players can be based upon).

    In the end, I think libraries have a longer life than applications. Some applications come and go. A library, on the other hand, can be used by several applications. If the library is well written, well documented, well unit-tested etc, and flexible enough, it will survive a much longer time. There will be more contributors. The library, if written in C/GObject Introspeciton, can be used from several languages. Etc.

    I don’t know a lot about the internals of GTK+ music players, but maybe there is some reusable code in Rhythmbox or another GNOME music player. But yeah, Rhythmbox doesn’t use Tracker (which may be a good thing, or not, I don’t know).

    1. I do know a music player library. RhythmCat is librhythmcat plus some UI pieces.

  3. Please make sure one can browse the local file system and set a default directory. ~/Music is not acceptable as the only directory allowed to have music in it. People want to share such as in families so being able to point to say /home/music for example is necessary.

    1. Craig Barnes Avatar
      Craig Barnes

      You can already do this now. Music uses Tracker to find music files. You can configure Tracker to index any directories you want and all the music found inside will be made visible in Music.

      If you have gnome-control-center installed, the options for this can be found in the “Search” section. Otherwise you can use the tracker-preferences program.

      Tracker is also used by many other apps as a file system indexer for finding documents, videos, git repos, etc. What and how it indexes is all fully configurable by the user – if the user cares to look. The defaults are just there for those who don’t care to look.

      1. Craig Barnes Avatar
        Craig Barnes

        Or you could just symlink ~/Music/shared/ to /home/music/ and let tracker follow the link.

      2. I suspect you haven’t actually tried your suggestion or you’d know that Gnome Music filters what it gets back from tracker and only display what’s in ~/Music (or whatever the XDG music directory is). Try it and you’ll see what I mean, you can tell tracker where your music is, but if it’s not in the XDG music directory, Gnome Music won’t show it.

        Additionally tracker doesn’t follow symlinks (at least I’ve never figured out how to get it to do so), so symlinks aren’t a usable workaround.

      3. Craig Barnes Avatar
        Craig Barnes

        @AR

        Yes you’re right, I didn’t try either of those suggestions, and indeed neither of them works. My mistake.

        I guess you could get even more creative and use bind mounts, or overlayfs, or add XDG_MUSIC_DIR=”/home/music” to ~/.config/user-dirs.dirs — but that’s venturing into hacks territory. It does seem pretty pointless for Music to add extra restrictions on top of Tracker.

      4. Oh man, like how hard can it be to just add, “browse for music” like almost every other application in the world does. This mentality of not allowing us the users to be able to choose is just plain broken.

        Fine let the default be ~/Music but at least give users the choice. We are free software not Apple.

      5. Craig Barnes Avatar
        Craig Barnes

        The reason I list those potential workarounds is because it might allow you to do what you want in a current release, without having to wait for a fix.

        If you want to see the issue fixed properly, a good start would be making a proper bug report. Another good idea would be to not make snide, passive-aggressive remarks at whoever maintains the project, like you’ve done here. That shit isn’t likely to fill them with any motivation to help you.

  4. I was going to suggest that Album Art should also be a data source (optionally implementing caching internally) but then I realized in GNOME Music lingo that “Data source” == “Music data source”. If so, perhaps you should rename “Data Source” to “Music Source”? seems more straight forward imo.

    Regardless – the new architecture seems much more logical and coherent indeed.

  5. Nicolas Will Avatar
    Nicolas Will

    Oh, please, please, take a look at Roon (https://roonlabs.com/). One of the few proprietary software/service/technology that I absolutely fell in love with. All cannot be done without a strong non-free backing service, being a competitor is not the goal either, but there is a lot that can be an inspiration for a great free software music platform!

  6. Couple of comments:

    Doesn’t grilo already give you a multi-backend way of finding music and other media? Adding support for multiple backends in GNOME Music itself seems a bit confusing…
    It would be nice if GNOME Music itself let me know how I can add other directories with music in them to the index. I was pleased to find out by reading the above that I can do so in Control Center, but it’s really not discoverable at all! Something as simple as a menu item that opens up Control Center → Search → Music would be a great help.

  7. Perhaps integrate the effort in/with GNOME Music Player Client https://gmpclient.org/

  8. Why do I need to install Nautilus to use Gnome Music (Debian)? I would like to try it with XFCE.

    Thank you

  9. Is it possible to change tracker so it can let applications choose and add directories for it to search? When a directory is added to the engine, tracker will do a full search in it, so if another application add/enable the same directory in your preferences, the work would have been done already. This will probably help with the CPU usage and, of course, will help with the “which directories should be acceptable to search music?” question.

    Also, is possible to add to music “tag” reader that uses the path or any tool that search in online tools and add the correct tags? For the first, it could be used from the “root” in search. For example, ~/Music/Artist/Album/Music.mp3 would lead to Gnome-Music asking, starting from Music, how the relation could be done.
    For the second, would be just a option for the “Unknown” section, to do a online search, so it can add tags, or install/open a program so the correct tags can be added.

    1. About the first paragraph:
      The add/enable would look to enable from the previous added or ask to add another directory.

      About the last:
      “Unknown”, as artist and/or album. If, even without id3tag, the music is sortable from it’s path, would be good to let this be done. The user could sort as done in ExFalso and/or with some common patterns..

      And thanks for all work done Georges
      Regards from Brasil o/

  10. […] the very end of last week, long-time GNOME developer Georges Basile Stavracas Neto wrote an interesting blog post about the future of the GNOME Music app, a music player distributed as part of the GNOME Stack, […]

  11. Simplification is ingenuity, sounds like some great work.

    Instead of playlists, albums and genres can we have Tags like Photos? I would prefer that playlists, albums and genres are all reserved tags and that I can add my own to organize music better.

    My 80 y/o grandfather uses Gnome Music and Gnome so whatever simplifications and buffs to it functioning smoothly and quickly are appreciated.

    I sometimes find that none of the layouts really make it easy to do what I want it to do.

    Since the app doesn’t leave the Music scope I would prefer a Welcome Screen that hybridized Artists, Songs and Playlists.

    And while this may be rooted in past user expectations a little I find browsing music by Album to be the most useless of ways, and thus not worthy of being the default view.

    Sure I like the pictures if the files have them in the album art but I think Albums is a thing made nearly obsolete by the Internet & Digital Media Distribution.

    I also think the 5 star rating system is obsolete – I think it would be cool to be able to give 1 to 100 stars to a song and order them by that numerical rating so that it’s easier to make more than 10 categories of music based on star ratings.

    I also think it would be cool to have rating degradation – a system whereby music rated say 5 stars in 2016 is different than music rated 5 stars in 2013 – because lets be honest we all get tired of old stuff we loved.

  12. I’m not sure where exactly this fits into the architecture plan, but the killer feature GNOME Music is missing for me is the ability to have multiple independent audio libraries.

    Namely, I listen to (i) music, (ii) podcasts, and (iii) audio books. Those content types are not interchangable, any audio players that treat all audio like a monolithic library don’t work for me, because I acquire, listen to, delete, and otherwise treat those files in distinctly different ways. Case in point: I don’t want a random chapter popping into a shuffled audio mix.

    There are only a handful of Linux audio players that actually care about this feature (including Rhythmbox, where you have to manually add multiple library locations with a gconf editor, which is far from ideal). Not having it keeps GNOME Music from being useful to me.

  13. […] we want this cycle -besides finishing what we started last cycle- is doing the rework Feaneron blogged about earlier: having a single core model that drives the different views. This would solve a […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.