What features should be added to theming spec?

[Dook]

From what I can tell, it's been almost 10 years since the theming spec has had any major additions. There's still some pretty big changes that never got merged (like for example this one from jdgordon that would've added multiple album art tags in one file) I thought I'd try get some discussion going to see what things could be changed or added to the spec in the future. Of course the biggest thing has to be that any tags in the existing spec cannot be changed in order maintain compatability.

Some points I can think of to start:

• How can the skinned menu list feature be improved to support user's chosen line selector colours, fonts of different sizes etc.
• What changes can be made to support features like Lockscreens?
• How would a dynamic colour system based on the current song's album art work? What would it look like?
• Are there other parts of the Rockbox system that should be exposed for people to theme? The quickcreen, colour selection screen, or even keyboard?
• Should the USB screen be more theme-able? Is the USB image something which themes should be able to add for themselves?

[Frankenpod]

Maybe an option when displaying album art to rotate it?

  Either in increments of 90degrees in the plane of the screen (i.e. ability to show it sideways or upside down) or (presumably more complex and more work for the device's processor) to display it with a perspective change, as if rotated perpendicular to the screen (kind of like what happens with the Picture Flow plugin or the ipod's original 'cover flow').  Some themes already have a kind of faked perspective rotation effect which really just clips off the edges of the image but doesn't actually change the perspective.

[iPodVT]

I would love it if my theme could make a call that specified the pathname to a file - presumably a text file - and then get returned the contents of the file in the form of a string.  Of course, the amount of text returned would have to be fairly limited.  Maybe the text file could contain a number of strings delimited by carriage returns, and then the call from the theme could specify the pathname to the file and the index of the desired string.  A failed call could just return a zero length string.  I would be thrilled even if it was only one short string per call and/or per file.

[speachy]

I would love it if my theme could make a call that specified the pathname to a file - presumably a text file - and then get returned the contents of the file in the form of a string.  Of course, the amount of text returned would have to be fairly limited.  Maybe the text file could contain a number of strings delimited by carriage returns, and then the call from the theme could specify the pathname to the file and the index of the desired string.  A failed call could just return a zero length string.  I would be thrilled even if it was only one short string per call and/or per file.

Can you provide an example of the sorts of strings you have in mind?

Because this has some significant implication for our ability to localize/translate (and voice) what's shown in the UI.

[iPodVT]

At the moment my main interest is in being able to specify a name to be displayed without having to hardcode that name into the .sbs file.  I have a number of iPods, each with a different username.  I'm currently able to kludge a solution by appending each iPod's name onto the name of its playlist catalog directory, and then I retrieve the name with %St(playlist catalog directory).  So if my iPod's name is "Bed_Pod", I name the playlist catalog directory "PlaylistsBed_Pod" and then call %ss(10,-,%St(playlist catalog directory)) to display the correct username.  This is kind of ugly but okay for my own personal use, but if I ever get my theme (not to mention my courage) to the point where I'm ready to publish it, it would be much better if the playlist catalog directory could have the default "Playlists" name (or any other name that the user chooses) and then the user could optionally place their userName in a file called something like userName.txt.

Of course, having access to information in text files would also open up lots of other possibilities.

[speachy]

I'm not a fan of themes having untranslatable strings. 

For this specific use case, I wonder if it doesn't make more sense to add a global configuration option to give a given device a unique name (defaulting to "rockbox player" or "ipod4g" or whatever) then give the theme engine access to that?  This way it's clear that it's a user-specified string.

[iPodVT]

For this specific use case, I wonder if it doesn't make more sense to add a global configuration option to give a given device a unique name (defaulting to "rockbox player" or "ipod4g" or whatever) then give the theme engine access to that?  This way it's clear that it's a user-specified string.

That sounds good, but I'm not sure I understand the specifics:  do you mean there would be something in Settings that would allow the user to specify a piece of text that a theme could retrieve?  In any case, I think the mechanism should allow for the possibility that the data might be zero length (either by default or by the user's choice) and then the theme, recognizing the absence, could knowingly do the right thing.

[Dook]

Maybe an option when displaying album art to rotate it?

  Either in increments of 90degrees in the plane of the screen (i.e. ability to show it sideways or upside down) or (presumably more complex and more work for the device's processor) to display it with a perspective change, as if rotated perpendicular to the screen (kind of like what happens with the Picture Flow plugin or the ipod's original 'cover flow').  Some themes already have a kind of faked perspective rotation effect which really just clips off the edges of the image but doesn't actually change the perspective.

Yeah, I'd like to see have a lot more options with album art. I've seen some people try and build a vertical UI for ipods, maybe some kind of different viewport that is drawn at a specific angle could be a solution?