The basic version of my font package is kind of finished, I have to restrain myself from tweaking the fonts too much but for now it’s a huge improvement over just having the legacy bitmap font.
In other news I’ve decided it’s probably easier to build my own hardware than to write drivers for everybody else’s so I’ll be adding some more FPGAs to my workflow but that may be pretty gradual before I get new tech working.
I have nothing to do with the Australian government, they keep me here as a prisoner of war and I only use their paperwork because I’m forced to. My citizenship is Egyptian, my family were removed from Egypt during Britain’s Jewish holy war against us and were never welcomed by the British or Australian citizenship system, they all act the same as “white” Jews towards me and they consider Egyptians to be an enemy race.
Have been asking since I was a kid and not one person in this alleged country has been able to explain to me how their damn citizenship system works. I’ve never been treated as a citizen in any country except Egypt.
Work is underway on theming and font support, in a few days I should have some more styles to show off!
If they can’t fix my birth certificate or offer me some other citizenship paperwork I think I will just have to start doing the job of a government here.
I just want a piece of id documentation with my real name on it. I fucking hate this shit where they force us to use biblical names.
Semantic styling should be highly reliable but developers should be aware of some potential pitfalls.
Although semantic styling will generally work in all cases including menus, backends for third-party platforms may be more limited and the system may be unable to fit all the styling information into the standard menus on a given platform.
This shouldn’t be an everyday problem but may impact some early software porting efforts and could require some design attention: You may want to leave menu items in the default settings instead just for consistency or reliability.
If you’re developing a UI for a smart watch or for an industrial screen with limited or no colour support then you may just need to use a simpler GUI system.
The current fonts in my system are extremely limited and the selection of fonts probably won’t be stable for a while, so don’t expect fonts to be reliable across different backends or across different system versions!
A GUI item either does or does not have a semantic style applied. This means there is no inbetween state where an item might have some semantic style information applied, it’s either turned on or turned off per-item.
Then the GUI uses no semantic styling internally, so it just draws things like buttons using whatever settings are applied by the system.
This usually means the rendering and colour choices are quite different, e.g. the default may be to use a built in font renderer from the backend instead of actually selecting a font internally.
If it’s blue it’s blue. If it’s bold it’s drawn thickly. If it’s Sans Serif or Times New Roman then the system should ideally try it’s best to find the correct matching font or inform the app of a problem otherwise.
The styling information is considered mission critical and is applied as much as possible, even if the system thinks blurple is a stupid colour, and it only affects layout when it changes the size of an item (e.g. larger/smaller font).
The semantic style information consists of a pixel colour (optional), a font (optional) and a set of flags. This means that, while semantic styling is decisively either turned on or turned off, when turned on it can also be used to indicate especially plain items. Themed backends in the future can use this mode to select more simple or less distracting rendering than the default.
This behaviour shouldn’t be expected to be perfect but should be reliable. For example if you set a component to dark purple it may look more blueish or more reddish or darker or lighter depending on factors like theme, graphics backend, screen settings and button mode – however the button should be recognisably marked as being some usable approximation of your dark purple setting.
If a system theme or GUI backend can’t deal properly with the styling information then the user should still be informed of it, e.g. “dear blind person, this button in the thermostat is marked Red”. In more typical cases, this means that themes should fall back to the built-in rendering if they can’t process the semantic style (it’s considered more important than aesthetic theming).
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.
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.
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.
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.
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.
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.
This has been the thought on the back of my mind for a long time. I’m limited by location in rural Australia as getting online at all here is a bit of a miracle but I want to ideally develop some public-facing infrastructure that is a bit less bogged down by the corporate greed of silicon valley.
This might involve linking some public cloud servers with my existing (but very modest) compute cluster and exposing it as a research system for developers… But ideally I should get to a city (totally unaffordable here) where I can regular infrastructure. I will have to just see what I can do.