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:
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 Backend manages:
- 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:
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.
Leave a Reply