HTML Post Support Test

What this validates

• HTML metadata now comes from proper HTML elements.
• Raw HTML content is rendered in the post body.
• The shared page shell (header, nav, footer) remains intact.

IdealOS Thinking

One of my original IdealOS blog posts from 2017 showed up on the front page of Hackernews the other day (comments here). This got me thinking about IdealOS again. I haven’t worked on it in a couple of years, but as I read through the comments and links to articles by people with similar ideas, I came to a realization. I am still working on it. Maybe not directly, but I’m still exploring ideas that are needed to build IdealOS. So with that in mind let’s take a look at what I’ve been working on lately.

Tiny Apps

One of the keys to IdealOS actually being “ideal” is having apps which are tiny. They should have very little code. The less code there is the less space there is for bugs to hide. Tiny apps also tend to run faster and be easier to maintain. If we assume an always accessible database, then theoretically a lot of the complexity of writing an app can go away, at least if we have the right abstractions.

To that end I’ve been prototyping a React library that lets you define a data schema, then use it as the core data structure in your React app without having to manage state updates, and automatically persisting to local storage, resulting in an extremely compact app.

Here’s a simple example of a todo list item:

const TodoItem = makeMap({
title: makeString("untitled"),
completed: makeBoolean(false),
})
type TodoItemType = typeof TodoItem
const TodoList = makeList<TodoItemType>(TodoItem)
    type TodolistType = typeof TodoList

That’s it. That is all of the code that we need to make a simple todo list. Rendered it looks like this:

Events and change propagation all happen internal to the structure, so your app doesn’t need to manage updates when new items are added. It will just do the right thing.

ListView

ListView does not know, however, what our TodoItem object actually is so cannot render the items the way we want. By default it will call item.toString() which recursively calls toString() on the child properties. That is the output we saw above.

The next step is to tell the ListView how to render TodoItems using a renderer. If we just want a different string representation we can give it a StringRenderer like this:

const SimpleTodoItemRenderer:StringRenderer<TodoItemType>
    = (item:TodoItemType) => {
    return item.get('completed') + " " + item.get('title')
    }

Next Time

So what have we learned?

1. All of my research taught me that the SPI bus is the bottleneck, and there's no way to get more than 7fps for a full screen refresh. However, partial screen refreshes can quite fast and the displayio API was designed to enable this. They've done a great job. I don't think I could do better without hardware changes.
2. Make sure you set the SPI bus to it's max speed. The default may be much lower than the component is capable of.
3. Design your graphics an animation around updating the fewest number of pixels.
4. Use the backbuffer to your advantage. You can make complex graphics as long as the number of pixels changed per frame is small. Cool particle effects should be possible with this technique.