Semantic Styling
Rather than starting with 9-part theming like most GUI toolkits I’ve instead kept the blocky 80s/90s aesthetic and have introduced a concept called Semantic Styles.
A Semantic Style is a set of styling information applied to a single GUI item to indicate a special use for the item, the idea is that this is a separate behaviour to theming but also makes common needs of theming very easy.
Example
Let’s say you’re building a thermostat control app, you want a simple interface but it should be functional and look nice. Theming and semantic styles go hand in hand in this example.
When To Use Theming
It’s a thermostat app, so you might want it to have a general summer/winter kind of theming mode maybe with some subtle colouration and background imagery.
This would ideally be handled by a theme, and this behaviour ideally wouldn’t impact the operation of the app: If a user decides “I don’t like this, I want it to use my custom theme instead” the thermostat app would still work fine and wouldn’t be any harder to use.
When To Use Semantic Styles
Being a thermostat app, the user would probably expect a simple button to make it hotter and a simple button to make it colder, as well as any more advanced or automatic settings.
This is where Semantic Styles come in, because you probably want the “Hotter” and “Colder” buttons to stand out in some way that’s appropriate to the application (i.e. the “Hotter” button should be red and the “Colder” button should be blue).
This is a separate concern to theming because it impacts the usability of the app more directly than just having a good or bad overall appearance.
The real mechanical difference is that frontends for disabled people or for running your app in unusual circumstances can still make use of this “semantic” information even if they don’t use regular GUI styling.
The API is also simpler and more reliable than designing or configuring themes would be, so this can also be used in cases where it is just for aesthetic purposes e.g. “my app needs more colour” or “the client’s favourite colour is green, so let’s just make this green”. In other words, this is for mission-critical theming.
Additional Advantages
Having a robust concept of “semantic styles” is both simpler than implementing full theming (which will probably come around or after the next releases) and also makes it easy to implement things like font pickers and colour pickers, because the font and colour can be applied easily to the picker buttons without needing full custom rendering for everything.
Integrated Vector Graphics
Most modern graphics backends probably have some way of storing & replaying commands internally but this isn’t always documented as a major feature.
My approach is a bit different, direct rendering in custom controls is replaced with simple “Graph” items that display a command sequence (either a static image or the commands can be appended or reset from scratch as needed). This allows for roughly the same behaviour as custom controls but also makes it easier to work with vector images (since the built in format is just the standard drawing commands).
This deep integration will also allow vector images to take advantage of some theming & semantic style information, and this can probably also be done with pixmap images embedded in the vectors (using simple palette techniques, similar to changing a character’s colour in early video games).
This format is notably simpler than standards like PDF while also effectively having most of the same functionality (since nobody realistically needs to run DOOM inside a vector image file, only some touchups would be needed for nicer fonts etc.). Simple extensions to the format can be added in the future to better deal with printing backends and other things.
