Blog

  • Hardware Announcements Will Follow

    I’ve been working these CPUs a little hard, some big little things are coming to replace them.

  • Fonts, Hardware Work

    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.

  • More Screenshots Soon!

    Work is underway on theming and font support, in a few days I should have some more styles to show off!

  • Problems With Semantic Styling

    Semantic styling should be highly reliable but developers should be aware of some potential pitfalls.

    Menus Can Be A Grey Area

    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.

    The Screen/Backend Could Be Limited

    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.

    Don’t Rely Too Much On Fonts

    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!

  • How Semantic Styling Works

    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.

    When Semantic Styling Is Off

    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.

    When Semantic Styling Is Turned On

    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).

    It Can Draw Things Plainly Too!

    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.

    Imperfect But Reliable

    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).

  • A Couple Of Advances In GUI Tech

    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.

  • How To Democratise Supercomputing

    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.

  • I’m Sick Of People In Australia Acting Like We Can’t Have Tech Careers Too

    Why not?

    Why is an Egyptian not allowed to write code in their society? We invented infix notation, SSL and modern semiconductor manufacturing. What have the white people done, programmed it to be 50x slower? Westerners are useless at coding that’s why they’re so weak against the AIs.

  • “White” People

    Don’t seem to want Egyptians living in their countries or in our own. Seems impossible to get a normal rental anywhere, in Australia they treat me like I have to be homeless to live in their country (meanwhile they control the paperwork so I can’t even leave without their permission).

    Almost all of the racists now are darkies too, they all have darker skin than me and look like Italian Negroes but they support white supremacist rhetoric. This woman looks straight up Black compared to me, as I’m sure the Indian woman at the job network who recently tried to mock me over the housing situation did.

    These “white” people are just the same as Africans & Arabs but have been convinced by their idiot books that they are biologically different to the rest of us. May the future have no place for such idiocy.

  • Severe Progress

    Many late nights have been spent hunched over the laptop, the progress has been harsh on my body. Work has returned to the GUI toolkit & applications now that the Pascal environment is becoming more stable.

    Rapid Prototyping Underway

    It is now becoming much, much easier to throw together quick GUI mockups, which is allowing me to start developing many applications as simple GUI examples and I’m starting to get an idea now of which ones I want to keep developing into full apps.

    Many New GUI Item Types

    While initially designed just for menus & buttons, the GUI toolkit has since evolved to include tables, scrollable areas, text editing and more. Now I’m extending it with other features I initially missed such as progress bars, tabbed interfaces and more.

    The new compiler is making it much easier to develop reusable compound items as well, some like a standard application “About” dialog have already been added and soon work will begin on file dialogs and other things.

    Now that the selection of item types is starting to feel close to complete more work can be put into improving core features like styling…

    PDFs Will Be Banned

    Work has begun on a new vector graphics format, this will be heavily integrated into the GUI and the Pascal environment allowing for vector artwork to effortlessly adapt to system themes & preferences.

    In the future this could be used to drive printers or other things as well, for now it will be primarily used for fonts & icons within my GUI but a more flexible backend is planned!

    Advantages Of Simpler Formats

    This “vector” art format will probably also be expanded to cover use of pixmap/bitmap data as well, since it would be pointless to require a second container format and a second set of APIs when bitmap data can just as easily be stored as a vector file that only contains a bitmap object.

    This would probably be a pain in many other vector file formats, but because I’m using a straightforward series of commands encoded in a plain binary format the pixel data can just be placed in a command following any necessary dimensions & formatting information.