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): https://gist.github.com/vidarh/1cdbfcdf3cfd8d25a247243963e55a66

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.

Heh, yeah, that’s part of what’s currently keeping me on X. I use little more than a bunch of shells and Chrome, so there’s not many incentives for me to switch. All of my Ruby X tools are very light on the X11 API use, so they’ll eventually be fairly simple to migrate over, but the window manager vs. compositor situation is frustrating.

I’m somewhat tempted to hack together some FrankenCompositor based on wlroots that implements the bare minimum of the X11 protocol to allow an X11 window manager to to manage the windows. The X11 protocol itself is simple, and while making every WM run would be a ton of work, if you first have a Wayland compositor making it possible to run simpler WMs wouldn’t actually necessarily be so bad. Not likely to happen anytime soon, though, it’s not exactly necessary and I’m not that much of a masochist :)

A somewhat more sane variant might be FFI bindings for wlroots so it’s possible to use it to build a compositor, but that too seems an awful lot more work than an X window manager.

That’s an interesting one I’d missed. Thanks :)

It might just tempt me to ditch bspwm, or at least experiment. I use little enough of bspwm capabilities, so it might be feasible. I have also lightly toyed with the idea of writing my own, as since I don’t use menu bars etc. even on my floating screen (the “menu bars” in my desktop manager are just client rendered titles) I really need very few capabilities. Basically pretty much just a placement function similar-ish to bspwm, and the ability to move and resize and float windows.

On the other hand, a truly minimalist WM is <100 lines, so I might consider writing one from scratch too (I’d need to update the Ruby X11 binding to handle StructureNotify events and add a few more calls, but that’s pretty trivial). Though at this point we’re quickly approaching zealotry :) It would be fun, though. Maybe when I’m done replacing the terminal fully…

Not everything is on Github yet, and much of it is messy and with dependencies on my environment (in the process of cleaning that up), but if you click through the “cross-posted to:” link there are a bunch of links to repo’s of what I have pushed so far.

Thanks. I’m in no rush, but yeah, it’s all very small. They depend pretty much on a handful of X calls at the moment, and aiming to isolate that in a couple of very small classes, so should be very simple. Hoping to clean it up and push more of these to github soon.

I did some experiments with DragonRuby a while ago, and it was really fun to play with. Wish I had time for a game project…

This is basically the concept of a Webring, and used to be big. Some were fixed (as in the path through the ring was always the same), but some were more flexible or random or semi-random.

A decentralised approach would be new, and not necessarily too hard since the dataset for each ring would be small, so each member could just store all or a subset of the entries in their ring and submit updates to their “neighbours” in the ring that’d eventually spread out to everyone. The challenge is moderation - you’ll still end up with some entities that have a privileged position to weed out bad entries, because the appeal was always to a large extent to make discovery “someone else’s problem” and the moment you let someone put links on your site someone will try to abuse it.