Disclaimer
The below information is available simply for drafting purposes and should not be considered an officially scheduled feature. The below information is related to the Google Summer of Code (SoC) Project Proposal by RobFrawley. Those interested in helping develop this possible feature are welcome to add comments/edit the page below.
General Description
The current
CustomWPS system allows for simple customization, based on newlines and line height of the current font laid on top of a backdrop image. This makes themes break easily: simply changing a font size or family can cause the text to become misaligned with the backdrop image. The goal of
ViewDrawing is to, in combination with
ViewPorts, provide an elegant pixel-based solution involving spaces, or quadrants (
ViewPorts) of content. Additionally,
ViewDrawing and
ViewPorts would expand the customizations of the current
CustomWPS system and allow theming of both the browsing and playing screens.
Goals
- Provide a simple and clean markup language for theming based on three files
- browsing.draw for the browsing menus
- settings.draw for the settings menus
- playing.draw for the playing screen
- A cleaner and confined theme directory system (see ViewDrawing#File_Structure for more information)
- Pixel based positioning of quadrants (ViewPorts)
- Backwards compatibility without hindering forward movement
- UI which reacts similarly in speed, or faster - a slower UI is not an option
File Structure
The current
CustomWPS system has folders throughout the root rockbox folder pertaining to theme elements. The proposed folder structure below would work to help centralize these folders.
- /rockbox
- root_folder_1
- [...]
- themes/
- _fonts
- theme_1
- [...]
- fonts
- backgrounds
- images
- drawings
- browsing.draw
- settings.draw
- playing.draw
To help explain the redundant font folders in the proposed file structure (
ViewDrawing#File_Structure), I will briefly describe my interpretation on parsing the drawing (.draw) files as they pertain to fonts. Whenever a font declaration is found, the parser will first search the theme font folder (/rockbox/themes/theme_1/fonts). If the font cannot be found, the parser will then check the lower font folder (/rockbox/themes/_fonts). The lower font folder will contain fonts which come with Rockbox by default. Having an additional fonts folder in the specific theme folder itself allows users to simply copy the whole theme folder (with necessary additional fonts enclosed) into the themes folder (/rockbox/themes/). This should greatly simplify theme instillation for the average user.
Here is a modified version of the file structure based on some feedback:
- /rockbox
- root_folder_1
- [...]
- themes/
- fonts
- backgrounds
- images
- drawings
- theme_1
- browsing.draw
- settings.draw
- playing.draw
And another:
- /rockbox
- root_folder_1
- [...]
- themes/
- fonts
- backgrounds
- images
- drawings
- theme_1
- browsing.draw
- settings.draw
- playing.draw
- theme_2
- browsing.draw
- playing.draw
- theme_3
- browsing.draw
- settings.draw
- playing.draw
With the above method, different themes could be set for different player states: browsing, settings, playing.
Parsing and Syntax
Much though needs to go into the parsing and syntax of the drawing files (.draw), which handle the customizing of their respective screens. Currently, I think this needs to be discussed at length with core developers. Ideas are welcome!
Additional Ideas
Some ideas that have been discussed on IRC and on the official Google Summer of Code pages. These ideas really need some eyes looking at them and comments:
- Compiled Theme Drawing Files
- Perhaps utilizing a JIT (Just-In-Time) compiler?
- Compiled themes would have to be capable of reverting to their original text form, as many new themers use other themes to help them learn
- Perhaps Rockbox can compile the theme into a _compiled folder (/rockbox/themes/theme_1/_compiled) the first time the theme is selected?
Copyright © by the contributing authors.