The age matters less than the power-dynamics of her being his nanny.

I’m not sure if “optimized” is the right word for my stack at the moment. Optimized in the sense that it is small, sure, but it does come at a performance cost - as much as I love Ruby, e.g. doing font rendering in Ruby is only viable because you only need to render each glyph once per size you use, for example. But I feel the performance tradeoff is acceptable. For me at least.

The terminal is also nothing “special” yet, other than the fact it’s written in Ruby, and uses that Ruby font-renderer. It needs some serious bug fixes and cleanups and then that too will go on Github.

For me the tradeoff is that I get full control, and there are a few things I want to experiment with:

• Since it can parse escape codes, there’s nothing preventing a thin IO wrapper so it’s possible to use the backend to output to an X11 window. Benefits of that would be being able to e.g. use part of a window for text output while rendering other things in the rest of the window, or plugging in your own code to augment the rendering in various ways.

• But if you do that, you can strip out the escape code parsing, or bypass it, and use the underlying terminal buffer for the same purpose. E.g. my text editor already renders to a terminal-like buffer, and so when running under X it’d save going through the terminal pipeline, and I’d have the option of “upgrading” its rendering while keeping most of it pure text.

• I’d like to play with ways to do filtering and post-processing of content. E.g. highlighting based on running Ruby code over the output.

Especially since a large part of my use is my editor, augmenting the backend with support for small “upgrades” w/GUI features, like letting Ruby apps that pull in the backend control and respond to a scrollbar in the terminal, or “replace” the scrollback buffer w/control over the editors buffer, or plugins to add a minimap, to make it really easy to write Ruby apps that work in any terminal but that can get extra features when it can open its own windows would be interesting.

At this point my window manager, terminal, file manager, and text editor, as well as a bunch of utilities like contextual popup-menus for my file manager (similar to 9menu, fed by a script) are written in pure Ruby, including the X11 client bindings and the TrueType font-renderer. I really would love to see Ruby get more use outside of Rails, as I have no interest in Rails, and Ruby has a lot to offer there. E.g. you might think it’d be too slow for a font-renderer, and while it’s slow-ish you only need to render each glyph once per size as you use them so it works just fine and the whole font renderer is only 588 lines currently… Extend this across many of your main tools and you gain a system far easier to understand and modify to my own needs. E.g. my terminal is about 1800 lines of code. Xterm is about 88,000. Of course xterm does more, but most of things I don’t need. Trying to add features I want to xterm would be a massive pain; adding it to 1800 lines of Ruby on the other hand is comparatively easy.

I’m slowly packaging up more of these tools, but the big caveat is that I’m not really writing these “for users” but for my own use, and I have peculiar preferences (e.g. very minimalist) and so these would not be pleasant for others to actually use, hence the over the top warnings :)

It’s surprisingly easy to get an absolutely minimal wm working, though. E.g. this was my very first version (based on a C example called TinyWM): gist.github.com/…/1cdbfcdf3cfd8d25a247243963e55a6…

That is in fact all you need to do for a minimalist wm (that one is “just” floating and just a single desktop).

99% of the pain past that is learning all the quirks of how X11 works more so than the rest of the logic. E.g. after restarting it last night, for some reason the grab of the windows key + mouse button “broke” without a single code change on my end. I’m doing something wrong, clearly, but last time I ran into this it eventually “resolved itself”, so it’s hard to debug…

But to use this at this point you really need to actually enjoy chasing down those things. Hopefully it’ll get closer to something usable for other people at some point down the line.

Except if they were it’d be well known, and no startup typically has contracts that doesn’t involve approvals for secondary sales at this kind of early stage because increasing the number of people on the cap table enough triggers nearly the same reporting requirements as being public, and is a massive burden. Just doesn’t work that way.

It’s also hilarious that you take posting an article that is at best neutral, with a message of doom and gloom about risks to their business, on Lemmy is something OpenAI would have any interest in. If I wanted to pump OpenAI there are better places to do it, and more positive spins to put on it.