#Wrap Up
In Dev Diary 8, I highlighted the following goals for Koto development over various development sessions for the second half of May:- Implement the most relevant aspects of the TOML-based configuration support, ranging from setting key changes to file saving.
- Update our database tracks to have a reference to the Koto Library it belongs to.
- Update our Koto library logic and start implementing support for multiple libraries.
#Goal: All Things Configuration
In Dev Diary 8, I discussed the start of the work I did on reading in various configuration values from our TOML-based configuration. This support leverages tomlc99 for reading in various values, however unfortunately it does not support any form of saving. One of the biggest goals for development these last couple weeks has been implementing configuration saving in a manner that reduces problems with scaling up our configuration options in the future. It took a couple attempts but in the end I am pretty happy with the end result. In terms of the implementation, we do the following:- When constructing our KotoConfig object, we define various GObject properties, such as what is shown in this document.
- Our property names are specifically written in a consistent manner that facilitates our iteration during saving, so that "ui-theme" would actually result in the parser saving the value of that property to "theme" in the "ui" section. We do the same for the theme-override boolean, as was as playback preferences. Adding a new setting is as simple as updating the config read logic and a single property setting for our GObject-based KotoConfig class.
- An option to enable the continuation of playback of a playlist after selecting to play a specific track in it. This also applies to albums.
- An option to maintain the shuffle throughout changes in the playlists (this is enabled by default). Building on this, I will be implementing per-Playlist shuffle configuration (which was requested in a Patreon survey), so our playback engine will take that into account as well.
- Theme settings for choosing between three built-in themes so far (wait whaaat) and disabling the theming outright. I'll be talking about this a bit in the Theming section. This will dynamically swap the CSS provider in the application or remove it entirely (if overriding).
#Goal: Work on Multi-Library support
Unfortunately I was not able to get around to updating our Koto library logic to the extent I wanted, however I did start on decoupling most of the application logic from the use of a specific (as in one) Koto Library as well as eliminating its tracking of indexed music artists. Now, when indexing a Koto Library, we will check if there are any KotoArtists in our "cartographer" (our struct of various key/value stores of artists, albums, and tracks) matching the artist name. If there is (such as coming from another library, or has already been indexed for this library), we will just use that existing Koto Artist. Otherwise, we will generate a new KotoArtist like previously and add it to the KotoCartographer map. Expanding on this, a bug we had where we were not generating album and disc views on initial indexing is fixed. Yay. Right now I am struggling to determine the best model for implementing indexing across multiple libraries. One approach is "top down", where we apply a KotoLibrary's type (audiobook, music, podcasts) to inner KotoArtists, which then understand how index operations should be performed based on the type (e.g. support albums / sub-folders for audiobooks or music, direct files under a KotoArtist for podcasts). Then it is a matter of determining where we should be doing the file indexing. The other approach is "bottom up", where we index all files, then work out way up to determine its parent folders (possibly album or artist) within a given Library. The intent of the multi-library support is to ensure we can account for scenarios where you have an artist in multiple libraries, no matter how niche or unlikely that is, across multiple directories, disks, and devices. The flexibility of a KotoLibrary could also then be exploited to more easily support libraries on removal devices like mobile phones and simplify syncing. So this is all something I am working on modeling via old fashion notebook paper and pencil before I spend more time on the code.#Theming
Across mostly the last development session for this month, I spent a fair bit of time refactoring our SASS styling to make it easier to develop "built-in" themes. To accomplish this, we use a fairly common approach of variable-based styling, where you define your color palette in a variables file and if necessary, any sort of custom mixins / functions (common in SASS and LESS). This is, by-and-large, how variants of GTK themes work, and it is the same model Koto follows (in fact, I used GTK4's changes to their built-in theming as a reference point).
So like shown in the featured image and again above, we now have three built-in themes:
- Dark (default)
- Light - For those that like staring at the sun.
- Gruvbox - Inspired by Gruvbox theming in various IDEs and Ubuntu's old Ambiance / Human themes from the ol' days.
#Coming Up
During the first couple weeks of June, my goals are:- Settle on a model I am satisfied with for multi Koto Libraries and implement it. All of it.
- Implement per-Playlist settings such as randomization and model (moving that out of the database too).
- Implement a Solarized built-in theme, since that is a fairly popular stylistic choice. I would love to hear your ideas on additional themes too, even silly / fun ones!