My only gripe (and this goes for almost any open source project) is this: please include screenshots! Any program/service that has front-facing UI should have visual references, instead of making users build/run everything just to “see” it.
I'll see about adding, some, but see links elsewhere in this thread to a couple, and note that you can't really see much of this wm, as in the style of e.g. bspwm it has no window decorations whatsoever beyond a 1 pixel rectangle.
That's great. I still suggest caution even you try to test it, but having that a background with wms like that makes you less likely than most to hose your setup...
I suspect full screen Emacs in gnome, while not brilliantly efficient, is close enough to this project that I may as well stick with the mostly inert gnome layer
The maintainers are conservative about breaking changes. Almost all features are hidden behind “use” statements: for example, “use feature "bitwise"” splits the questionable & operators into & for numbers and &. for bitstrings. But old code will work exactly the same.
There are a few deprecations and things which have been removed from the language…like idioms that relied on interpreter bugs and have been obsolete for 20 years.
But if you run a Perl script without use strict, use warnings, or new command line flags, you’ll get a Perl experience largely unchanged since the turn of the century.
I run RubyFlow and it's just a community link posting site for Rubyists, so feel free to update this to the URL of the actual project if you wish: https://github.com/vidarh/rubywm/tree/master .. RubyFlow runs on a teeny tiny Heroku instance so may not be too great at handling your traffic. It's about fifteen years old though and a single Ruby file, so I should probably rewrite it! ;-)
Is this really the same 16 year old RubyFlow that authenticates against GitHub? I found a copy looking for the source but it looks like it is literally 16 years old, and I'm thinking there's just no way the OIDC flow has been standing intact for that amount of time without any update... really? :D
The version you'll have seen is the original version that I "leaked" to someone else who wanted to run a similar site. I said they could make the code public, but I didn't want to maintain or stand by it. It underwent an entire rewrite about ten years ago which is the version that's live now and the auth flow has remained the same within that timeframe, at least, but https://github.com/omniauth/omniauth-github does the heavy lifting and has been updated as a dependency in that time.
I'll provide plenty more ca. 2011 level Ruby enthusiasm over the coming months - I have my editor, terminal, file manager and more to get pushed to or updated at Github.. :)
My Ruby compiler project has unfortunately been languishing for years due to lack of time. I keep hoping to do some more on it as I got it to the point where it was self-compiling, but it's not very high on my list at the moment (my list is long)
That said, lrama is "just" the parser generator, is it not? As far as I understand, the Prism parser built using Lrama still produces a C library, and requires Ruby's parse.y as input, and parse.y alone is twice the size of my entire compiler...
Both Lrama and Prism are great projects, and I might've be tempted if that was a "missing piece" to turn the compiler into something production-ready, but frankly updating the parser to handle more modern syntax is the easiest bit of what remains. The really big pieces are supporting Regex's and floats (Ruby's regexp implementation is roughly the size of my entire current compiler...), and a bunch of bug fixing. Whether I'll ever find time to get it there or not, we'll see.
Yeah, I've toyed with Mruby, and it's great. Same w/webasm support for Ruby. I think overall the huge improvements in the Ruby ecosystem kinda drove my own down the priority list - it was mostly educational to start with, but the better the various other Ruby implementations got the less of an incentive I got to try to turn it into anything more than that (and doing so would be a massive undertaking). Hitting the "self-compiling" milestone felt like it was a decent place to pause it, but I'd still love to find time to take it a few steps further. At least fixing the most egregious bugs (the compiler itself has various temporary workarounds for bugs to allow it to compile itself without triggering them, and I'm not happy about leaving it in a state where I can't at least strip those workarounds out).
Hah. I didn't think this was quite HN worthy at this point - the code is still a mess, and has plenty of bugs.
It is however the wm I actually use since I got frustrated with bspwm and did a very minimalist rewrite of TinyWM [1] in Ruby [2] and expanded it from there. It was painful the first few days until I'd had time to add multiple desktops and the start of a tiling mode. But at this point, it's "almost" pleasant for me.
The warnings are real, though, apart from the initial hyperbole - this is likely to break for you in all kinds of horrible ways still.
[EDIT2: As for a real example of the ways it can/will break: Right now, for some reason, after a restart without changing a single line, it's failing to grab super+buttons to move/resize windows; it doesn't really matter as I have keybindings for it and mostly use those, but, yeah, I'm doing something wrong somewhere and last time this happened the problem just went away by itself]
I use very few applications beyond (my own) terminal, (my own) polybar replacement, (my own) file manager, and a browser, and so once Chrome and my own apps mostly started working ok I've had very little incentive to make sure it behaves nicely with anything else and I know the distinction between different EWMH window types is incomplete and broken - just not in ways that usually affect my own use.
EDIT: Also a couple of quick notes on "design choices" to the extent this has been "designed" rather than accreted: As you can see in e.g. desktop.rb, quite a few places I've chosen to query and filter the top-level WindowManager class for a list of windows matching a given set of criteria. I did that on an experimental basis out of the idea that it was a waste of time to track precise state across multiple objects given that the total set of windows will always remain "small".
So the Window objects know the bare minimum state of the underlying X11 window that it needs to track, and the WindowManager class knows how to map an X11 window id to a Window object.
Other than that I avoid tracking state as much as possible, and even where I track state I try to avoid the need for full precision.
The one other place I must track state is the layout classes. Currently, only the basic tiling layout, which keeps a tree (that is currently a binary tree, but the array of nodes is there because I at one point thought I might allow more nodes) where the leaves keep track of which nodes have a defined place in the layout.
But even there, on updating the layout, I then crudely diff the currently known set of windows vs. the set of windows the layout believes are present and remove/add as needed.
I make a best effort to place new windows on map requests, but if anything breaks for any reason, the layout will "catch" up automatically and new windows will be placed. Given I use this daily while it is in flux and often broken because I've made a change and is testing it "live" on my desktop, this has turned out to be very helpful on occasion.
I can't make up my mind if this method (of constantly querying for attributes of every window) is a crude hack or quite elegant, but it works.
Many other things are not "designed". This is mostly very far from a good example of how to actually do things. E.g. "find_closest" used to pick a window to move to when you want to move directionally in a tiling layout is pretty much guaranteed to be possible to do much better with fewer lines of code once I actually get around to sitting down and thinking about it - the current version was cobbled together in a hurry because I was tired of not having the functionality and it "mostly works" as expected even though it's stupid.
I see C in there; that's cheating ;) (my WM uses a pure-Ruby X11 client library - there are no external C dependencies other than those of the Ruby implementation itself).
Though I sympathise - the sheer amount of effort to work with these, be it X11 or Wayland, is really annoying; the pure Ruby X11 gem I use is more lines of code than the window manager itself...
Yeah, I link against C libs because reimplementing the protocol seemed like a pain in the ass. The prevailing strategy seems to be to generate code based on XML protocol specs, and I'd prefer to avoid that crap. That would probably be less painful in Ruby as then the code could just be generated at runtime based on the XML.
Also since all the prepackaged wayland libs are heavy users of functions declared as `static inline` I have to create shims for those as they are not linkable. That part is a pain in the ass but pretty simple to resolve :)
And yeah, there is so much to set up just to get a bare minimum going. I guess that would be true in X11 too.
Oh, I absolutely don't judge you for those. Frankly part of the reason I went for a pure Ruby version instead of xlib was that the Xlib bindings for Ruby are also in an awful state, and someone else had done enough of the job on the pure Ruby bindings that it felt like it was doable incrementally as I needed various calls and not much worse than wrapping Xlib or xcb.
I like that there are no other dependencies, but I'd have sacrificed that if it was sufficiently much easier than the route I ended up taking (e.g. my terminal did start out linking to Xlib and using a tiny C extension; it's since been ripped out in favour of the pure Ruby bindings, since why not now that it's available, but it was a perfectly ok solution to start with).
The code generation is certainly a build step. This kind of code generation is common for interfaces defined outside of a project's programming language.
Writing a Wayland compositor from scratch means writing the whole display server. Wlroots readme describes it as "about 60,000 lines of code you were going to write anyway".
For comparison my wm is <1k lines.
So they're not equivalent - writing a Wayland compositor from scratch is more like writing the whole X server first, before even starting the WM.
I could use wlroots or another compositor as a starting point. I did look at it, but I'm still on X, and have no compelling reason to switch. Yet, anyway, and that adds to the "cost" for me in terms of disruption.
Where I could translate TinyWM into a few dozen lines of Ruby in a couple of hours and switch to actually using it and build from there, and "just" suffer some nuisance that I can slowly chip away at when I have time, even getting a basic wlroots binding + minimal compositor running seemed like a far more complex project.
I'm itching to figure out how to eat my way further down the stack, but I can't justify spending time on it unless I see a viable way of doing it (relatively) piecemeal.
E.g. I can restart my wm without exiting my X session, and so without losing any open applications. That gets far more disruptive for replacing the X server (whether by another X server or a Wayland compositor), and also allows for a far faster cycle - I can spot a problem, fix it, restart the WM and keep working without having to close everything...
I think if I was to do a Waylabd compositor, a first step would be to put things like window management beyond an IPC boundary, just like with X.
> I think if I was to do a Waylabd compositor, a first step would be to put things like window management beyond an IPC boundary, just like with X.
Isn't that already the case, by protocol definition? At least compositor and clients talk to each other over a pipe of some sort. It is actually a bit problematic because the way it is done put noticeable restrictions on both sides on processing things in time, because if it is full then shit hit the fan.
Not in Wayland, no. The only boundary is between the client and compositor. With X there is a boundary between the client and server, and between the server, wm, and compositor.
With Wayland the compositor serves the same function as both the X server, wm, and compositor in one. There's nothing inherent stopping the addition of extensions to allow the same split as in X (but the server/compositor split probably wouldn't be worth keeping - the WM is easier to split out because it's far less latency sensitive)
While it's not mandated, as I pointed out ("There's nothing inherent stopping the addition of extensions to allow the same split as in X"), I'm not aware of a single Wayland compositor for which it isn't true. If there is one, I'd love to hear about it.
Yikes. This is a great illustration of why I've steered clear of Wayland, when even with wlroots you end up with that much code to do that little.
TinyWM for X is 50 lines.
> Sway also has a "reload" feature that preserves all open applications.
As far as I understand, sway's reload just reloads the configuration. If Sway crashes, or you kill Sway's process, there's nothing left holding the sockets to the clients open, or managing the display - that's equivalent to killing the X server, not the wm.
With an X wm, as long as your x session isn't set up to quit when the wm quits, you can brutally shut down the wm, or it can crash, and the windows stay open, and you can restart your wm - or start another wm entirely - without losing any windows.
Of course, that's a new feature they're working on, only helps QT apps, and requires the toolkit to track state (and by the same virtue, looks like it would have worked fine with X11 if they wanted to). So this is more of an interesting related tidbit rather than a disagreement.
That's an interesting approach. It'd be easy enough to do for my own X apps as I'd mostly need to flush some caches and recreate windows and pixmaps. It'd generally be terminals that are most painful to use, and the terminal would be nearly trivial since they keep an buffer of the text anyway and so can trivially recreate the view once they succeed in reopening the window (the font rendering caches glyphs, and caches graphics contexts; just flushing those caches client side would make the terminal recreate them as needed)
Whether X or Wayland it would certainly make experimenting less painful. Browsers doesn't matter that much given they're reasonably decent at restoring.
(Another option there is xpra - "screen for X")
Fewer and fewer reasons not to start writing an X server ;)
> It'd generally be terminals that are most painful to use, and the terminal would be nearly trivial since they keep an buffer of the text anyway and so can trivially recreate the view once they succeed in reopening the window
The cheap version of this is just using tmux/screen, but yeah honestly I suspect a lot of programs are easy to make recreate their GUI state if you care to bother, it's just that not everyone does (or should; it's a trade off and display servers aren't usually that crashy).
i3wm, bspwm, etc, and many others have provided APIs like that "forever". The problem is that they're async and sit "besides" or "after" the actual window management.
E.g. one of the things I disliked about bspwm was that while I could get a feed of events and act on them, I couldn't intercept and modify or reject requests, so e.g. when a new window opened, bspwm would place it, and issue an event, and before my script could reconfigure the window it'd already be visible, so to get a floating desktop the way I wanted I ended up with windows flashing up in one location and then moving.
Put another way: The plethora of Wayland compositors is a strong demonstration of how these compositors don't give sufficient control via their external APIs, or people would write window managers for one or more of those compositors instead of writing more compositors.
I've been an X11 holdout since forever, but after nvidia proprietary drivers broke for the millionth time on a system upgrade, I switched over to Nouveau and the "Hyprland" tiling compositor on Wayland. It's the only setup that felt worth the upgrade to me. Setup was easy, animations are very slick (scroll down on the link below for a sample), and I've had no bugs or quirks. Highly recommend checking it out if you're bored or curious.
It looks great, but to me this is pretty much the opposite of what I want to use - the demo video at least is so busy, and full of transitions and other distractions.
There was a time I'd absolutely have loved something like that (and had all the window effects turned on when the first compositors started arriving) and it looks very cool, but other than translucency I've progressively stripped back everything.
I'll never try to compete with something like that on either effects or features. I might add some very minor eye candy. But that's fine - one of the things I've always loved about the Linux/Unix desktop is how you can get everything from the most minimalist to the effects-laden, and I've used wm's pretty much everywhere on that spectrum myself too over the years.
I sympathise re: drivers - that or the browsers finally abandoning X would be the only things that'd give me enough reason to switch. But I'd be more likely to switch if I get around to scratching the itch of yet another homegrown minimalist step down the stack... (I have a weird urge to write a Frankencompositor that supports Wayland clients and enough to support an out-of-band X11 style window manager and the brutally insecure X11 style event snooping and injection; partly because it'd really irritate some Wayland purists - I'm resisting that urge for now because it'd be a massive time-suck)
> It looks great, but to me this is pretty much the opposite of what I want to use - the demo video at least is so busy, and full of transitions and other distractions.
They are optional: you can make them last 100 ms, or just remove them.
Such "eyecandy" enable new uses: for example, all my windows are full screen, on they own desktop. No titlebar, no nothing because that's a waste of space. A quick animation when I change desktop helps me keep a mental map.
Also, hyprland great strength is it makes it not just possible but very easy to have a keyboard-centric workflow: you mix the tiling window manager strength with the traditional "windows" you can move with your mouse. F1 gets me to desktop 1 where my terminals live, Shift+F1 can send whatever window I'm using on desktop 1 to share it with the terminal for a while, Win + Left lets me adjust the tiling and Win + J lets me change from horizontal to vertical tiling
Last year was my year of Linux on the desktop, and I think I'll stay on Linux if only for hyprland.
> I have a weird urge to write a Frankencompositor that supports Wayland clients and enough to support an out-of-band X11 style window manager and the brutally insecure X11 style event snooping and injection; partly because it'd really irritate some Wayland purists
Check hyprctl: you can get a list of windows. With hyprland key bindings + basic shell scripts using hyprctl and ydotool to send key or mouse events, it's already possible!
From one of my simple scripts: `hyprctl dispatch focuswindow $WINDOW_ID | wl-paste | wl-copy -c` replaced `ydotool type "`wl-paste`"`
> They are optional: you can make them last 100 ms, or just remove them.
I'd rather have a codebase that doesn't have them so that I can work on a codebase that is tiny and focused on what I want when I want to change something. And I would need to make changes to the code base for it to suit me - see below.
> Also, hyprland great strength is it makes it not just possible but very easy to have a keyboard-centric workflow:
I already have a keyboard-centric workflow that does the things you list. There's nothing new in any of that. I have a floating desktop; I can move and resize them with the keyboard. I can move the tiling windows with the keyboard. I can swap individual windows, or swap entire subtrees, or flip their direction. All of that is trivial on almost any tiling wm.
> Check hyprctl: you can get a list of windows. With hyprland key bindings + basic shell scripts using hyprctl and ydotool to send key or mouse events, it's already possible!
This has the same flaw that was one of the reasons why I ditched bspwm - it allows getting events from it's 2nd socket - but not to intercept requests and being able to rewrite and choose whether to honor the requests or not. It does not have the flexibility I had in mind.
It has a lot of great functionality, but none of the things that I care about provide more than I already have, and some would set me back to the point I'd have to rewrite stuff again - and frankly just the build process for hyprland makes me break out in hives...
I am eyeing river wm. Because it has pluggable layout manager and controller via custom wayland protocols. Which means I can implement just those parts in my favourite lang to scratch the itch. Kudos to you going for the whole wm :)
An X11 wm is childs play compared to a Wayland compositor. I have been eyeing River and various other Wayland options too, in case I find myself compelled to switch to Wayland at some point, but the sheer complexity of the Wayland side has held me back.
Given that X11 is going away, the server (except for Xwayland) is unmaintained, and in a few years modern software just won't support it at all... the sooner you switch, the better.
There are plenty of Wayland compositors that supports X backends, so app support for X is moot because 1) most of the apps I run are my own - the only thing I really depend on is browsers, and 2) once Chrome and Firefox abandons X entirely, and no other browsers based on their engines supports X, there are options to run them with a Wayland compositor with an X backend in "kiosk mode" that basically gives them a single window just like before.
So that leaves how long I will have a working X server, and frankly I suspect I'll have ended up writing a display server years before that becomes an issue (whether that'll be X or Wayland or a mix, who knows, but I doubt I'll be able to resist very long).
It's just not a concern that's anywhere near the top of my list (or the top 100 of my list)
The funny thing is in theory it might work reasonably well, as Weston at least uses the DRI3 extension to get the underlying X server to just pass the DRI filedescriptors up, so if the rest also supports it you'd in theory just get a game of passing the fds through multiple layers and then the client doing direct rendering via shared memory. Though in practice there's of course plenty of things that might go wrong.
I go back and forth on this kind of thing; if the better option really is EOL, is it better to keep using it until it actually breaks, or is it better to take the pain up front? I don't have an actual answer in the general case, but on the bright side Xorg is still not dead even though the pro-Wayland crowd says so at every single opportunity; it has a nonzero number of maintainers, gets commits on a slow but regular cadence, and appears likely to continue working for the forseeable future. If we assume for a moment that the X server will really actually die when Red Hat stops maintaining it (questionable; the BSDs appear more attached to it than RH), that merely gives us until the end of RHEL 9 around 2032, which is far enough away that I feel comfortable not worrying about it.
Also, as sibling comment points out, a simple solution exists in the form of rootful xwayland; we can keep a working X11 environment and just swap out the actual rendering layer.
Or put differently: "Given that X11 is going away, the server (except for Xwayland) is unmaintained," just isn't true, and even if it was it wouldn't necessarily justify the claims you make on that basis.
A modern app needs to be able to run in datacenters and render on my GPU (whether desktop, laptop, tablet, or phone). That’s how and where our capacity is evolving.
If X dies, I assume we’re going to end up with Javascript or Wasm frontends to everything.
Maybe you'll end up with those frontends. I won't. Part of the point for me with my rewrites of essential parts of my computing experience is that I control an increasing proportion of my stack, and that proportion will keep increasing.
I think I've looked at Subtle, and it's interesting and worth a look, though it has design tradeoffs that doesn't fit me (and I wanted something entirely in Ruby rather than "just" scriptable in Ruby) But that's cool - my thought on this is that I'd rather have many tightly focused options than huge sprawling ones...
There is zero window decoration other than a 1pixel unshaped border, so there's not actually much to show, but here's an example of one of my tiling desktops w/a couple of my terminal windows running (one of the windows is st rather than my own):
> There is zero window decoration other than a 1pixel unshaped border, so there's not actually much to show, but here's an example of one of my tiling desktops w/a couple of my terminal windows running (one of the windows is st rather than my own):
Minimalism usually means fewer problems and bugs, it's not a bad thing.
> Here is one I did that shows a couple of file manager windows and my terminal and desktop switcher on my floating desktop:
Looks quite nice! I would suggest to add a few pictures to the GitHub.
Well, at this point you get few features but still lots of bugs ;) But yes, the minimalism is very much intentional - I have no interest in letting it grow all that much, and no interest in lots of decoration (I might add support for some; especially inspired by how Katriawm does it [1] - it basically just slaps images on each side in separate windows - it's high "bang for the bucks" in terms of flexibility for very little effort)
> Looks quite nice! I would suggest to add a few pictures to the GitHub.
So many keeps asking, so I guess I've have to add some...
I don’t run Linux anymore, and I am waiting for Apple to officially drop Intel support before swapping my laptop over, but one of my many software “bucket list” projects is to use a high level language to build a window manager. I was thinking about starting by porting DWM to some form of Lisp.
I love seeing these kinds of projects because it further validates that such an idea is feasible.
I know this is a joke, but, this goes right back to the first time I deployed Ruby and had "the speed discussion" with people. We deployed a Ruby queueing server that used 10x as much CPU in the Ruby code than our preceding C version spent in its code (that wording is careful). It was also 1/10th the LOC and had more features, and given we spent ca 1/10th of a 2006-era Xeon core in user space, it felt like a worthwhile sacrifice - the vast majority of time was spent in the kernel handling IO.
It was what made me fall in love with Ruby: There are so many spaces where the time is spent elsewhere and the time spent doing things slowly in Ruby (though much faster than it used to be) doesn't matter.
Like a window manager.
I've even made performance tradeoffs that makes it much slower: On every adjustment of the layout, I iterate over every single window the WM knows about to filter a list of the wm's on this desktop, that are visible, and compare that to a serialized list of every single window that exists in the layout tree.
Because it's fast enough, and it saves bothering to keep proper track of state, and makes some of the code simpler.
Knowing when you can afford to pick the slow options on purpose is powerful.
Knowing when you can't afford to, is also important.
As you can see if you dig into my code and then look at the X protocol implementation [1], the (incomplete) pure Ruby X11 binding takes up more lines of code than the WM. I was tempted to write the code to generate it from the XML spec, but a lot of the scaffolding for the current X11 binding predated my own work and it seemed like it'd be more and more painful work to write the generator than bite the bullet and do it manually (I don't expect to/care about supporting the whole protocol anyway). So a PHP version would be totally viable, just tedious.
If you do ever return to the idea of generating the X11 protocol code, you might find https://github.com/tonyg/xcb-shim interesting. I wrote it to simplify X11 implementation generally. I've used it just once, so far, though, to build a Squeak Smalltalk native X11 protocol implementation.
That's really useful, thank you. I have been considering massaging the Ruby version into a different structure as while the current one is fairly nice in some respects (such as providing support for both parsing and generating both "sides" of the protocol, entertaining my delusion of possible writing an X server), it also could definitely be faster and smaller...
Do get in touch if you do pick this up again, I'd be interested in collaborating or at least keeping track of how it goes; it was a bit lonely figuring out how to do X for Squeak in a vacuum :-)
Eh, it’s been fast in the real world for quite a while. I think it’s due to two main things:
1) Startup time had to be fast because of how it worked in its most common use case (yes, yes, FPM, but still) which tends to encourage or require making everything fast.
2) Writing C modules for PHP is relatively easy and it has a culture of anything halfway important being in C, going back to the early days of the language. The answer for how to be really fast with real-world workloads in almost every scripting language is basically “get out of it and into C ASAP” but PHP’s culture embraces that more than most.
Or maybe it's just a case of a job queue used for indexing new repositories being full. Not every instance of "X doesn't work" is the result of malicious intent.
Just like things are not instantly in the search index on Google and other websites doesn't mean someone is being evil by degrading the user experience.
My only gripe (and this goes for almost any open source project) is this: please include screenshots! Any program/service that has front-facing UI should have visual references, instead of making users build/run everything just to “see” it.