What the title says. It’s <1k lines of Ruby, and provides a basic tiling WM w/some support for floating windows. It’s minimalist, likely still buggy and definitely lacking in features, but some might find it interesting.
It is actually the WM I use day to day
This is experimental. It will eat your cat and burn down your house, format your hard drive and post all your secrets to Facebook.
this made my day, lol
During Christmas season I started reading about window managers because I was curious about it, and I found someone who made this but in Python. It was just an interesting thing but doesn’t feel like something you would put on your computer. Nice to see Ruby is able to achieve this, it feels pretty abandoned language outside of Rails.
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.
I’m fine with GNOME, but this long comment makes me feel like I’m missing a world if nice and optimized small software pieces which do exactly what you expect from them and nothing more.
Now I’m curious about the terminal you’re using!
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.
