Missing Features List

This page is more for myself to write down ideas or goals for working on Rockbox rather than a factual or objective list of something Rockbox actually needs. If you ever read previous versions of this page, please don’t consider them as they were incredibly naive about the possibilities of the theme engine in Rockbox before I studied it properly.

I added the Quicksettings tags to Rockbox in Summer 2024, included in the Rockbox 4.0 release. It provided two tags per Quicksetting direction, one for the name of the settings and one for it’s value. The code for this was taken directly from the Quicksettings code, though was still rather painful to transplant into the theme system.

These are features I’m currently working on programming within Rockbox’s source code.

I also refer to these as stylesheets, but this feature is a core requirement in my adwaitapod 4 vision. Essentially it will be a modified version of Bilgus’ file reading tag, but instead of outputting the text on screen it will attempt to set values to the foreground or background colour values. It will only use the text searching feature of Bilgus’ %ft, search for a name of a colour. Used like the following

%V(16,24,120,18,-)%Sf(main-text-colour,110000)%alSample Text

The first argument in the tag is the name of the token, while the second argument is optional providing a fallback colour if the file or token is not found.

The stylesheet file itself would ideally be linked within the config file for a theme, or perhaps via a setting and look like the following:

main-text-colour:110000
main-bg-colour:ffffff

This feature would open up two huge improvements. The first, solving the wave of clones of SNAZZY and similar themes that change just the colour values of the original. Having a forum thread where users could share stylesheets would suffice. It would also solve the issue of separate light and dark themes. Having a singular codebase, where the light or dark mode is decided by a stylesheet would allow simpler codebases for complex themes but also provides a route for simpler distribution and use by users.

This is almost certainly going to be what I work on next in the Rockbox codebase, needing it to even begin working on adwaitapod again. However I’ve learned a lot from my first endeavours in Rockbox so I’m hopefully it might be less painful.

While working within colour stuff, I intend to focus on this too. I really want to see custom menus begun more popular within theme making, but to do so they really need to support the user facing theme settings like those for setting the colour of the menu items. I need to figure out a good syntax for this.

These are either features I’m either vaguely thinking of adding, or not skilled enough to implement but would still find uses for eventually.

A tag which can tile an image across a given viewport. This could be useful for interesting backgrounds, or for reducing the size of assets needed if a design in your theme is simple enough that it could be tiled instead.

There’s a tag for the current playing song’s directory information: %d(n), which gets you the title of the 1st, 2nd, etc directory of the song’s filepath.

I think creating an analog of this for the current page would open up the ability to theme pages in the Database and File explorers.

For example, in the database you could have styled pages for artist or album pages specifically, using the following:

%?if(%l(2), =, Albums)<%Lt>

So this has always been on my list, but recently both my reasons for wanting it and the situation itself has changed.

Album Art in Rockbox is rather unusual, mostly that it is very static for lack of a better word. You pre-set a position once per file and it cannot be changed dynamically without going into the file itself and manually changing it.

Historically, people have wanted this to be different so they could make “Lockscreen” features with more interesting layouts. And for a while, that was why I wanted it too. However, exploring the file reading tag has opened up huge possibilities for customisation that I believe we are just beginning to see. My ultimate vision is to be able to keep adwaitapod in a single file for all 4 versions (classic and simplified in their light and dark modes.) Doing so would require moving the album art for simplified.

Recently there have been some updates on this. Bilgus began working on a patch to add more dynamic album art behaviour. I haven’t been able to test it yet, but based on Bilgus’ posts I would say it’s a 50/50 chance wether this happens.

Currently, if a menu viewport is set to have zero width and height, it will still render the contents in some situations. It’s not very consistent however. In some contexts like the Quickscreen, doing this will actually cause Rockbox to crash. Turning off viewports is important for features like Lockscreens, custom Quickscreens etc.

This is more of a bug fix than a feature request, but I believe a good solution here would be to not display the current page’s menu/system display if a menu viewport with zero width and height is turned on.

Displaying text over two lines is a great feature in my opinion, and one I’ve tried to create by hand in the likes of Themify. However this is massively imperfect and results in words being cut in half. My solution for this was to detect the presence of a space at certain parts of the song name, and break the text around that, but while it is still impossible to get a space character without using external files this will be a bulky solution. Adding a tag that would force a line to break like the %al tag forces a tag to align right would be an elegant solution design wise for this problem.