Published on 2 April 2020.
This is what I’ve been up to in March 2020:
I continued with RLiterate:
I tried Typometer to measure the time it takes from a kepress to a character appearing on the screen.
My first approach to speed up drawing was to draw immediately with
Update. That turned out to not work so well. I documented the problem in a blog post.
I concluded that to draw fast in RLiterate, an approach that works quite well is to only draw the part where the cursor is first, and draw everything else a few milliseconds later if there are no additional input events. For example, if a title is edited in the workspace, the table of contents might have to be redrawn as well. But it can wait, since the focus is not on it right now. I documented this behavior quite well here.
I think RLiterate’s true potential has not yet been explored. I think more paragraph types could add much value. It is something that I hope to explore after I finish RLiterate 2. But I don’t want to rush it. I want to write RLiterate 2 as clean as possible while still being capable of roughly what RLiterate (1) is.
I’m also thinking that RLiterate must be a multi process program. There is only so much you can do in GUI thread without it being sluggish. And using threads in Python does not help much since they are not truly run in parallell. So I’m thinking a multi process worker architecture is needed for heavy tasks. Like syntax highlighting, spell checking, generating files, etc. Then a little worker icon in toolbar to let the user know that stuff is happening in the background.
I read The Flawed History of Graphical User Interfaces. Computers don’t have to be what they are. We can make them to do anything. Including alternative user interfaces.
I read Some tentative guidelines for GUI composability. Isolated applications that can’t be composed is a bad idea. Yet the default.
I watched Tudor Gîrba - Moldable development. It is an interesting project that I want to explore more.
I read One rendering tree.
Well, the user interface framework has a tree, and somewhere in that tree, there is a canvas, and in that canvas … well, there is another world, with another tree. That these are different worlds, and different worlds means we cannot combine them easily. We do not want different worlds. We want just one. A seamless one.
This is something that might be useful for RLiterate. But that would require yet another complete rewrite. I should finish RLiterate 2 and learn from it. Then study one rendering tree. Then see if a third rewrite is suitable or not. But it is far away in the future.
I read 10 Most(ly dead) Influential Programming Languages. I would like to learn more APL. Perhaps implement my own APL to learn more.
Site proudly generated by Hakyll.