I also used StumpWM (https://stumpwm.github.io/) for years, primarily in purely-tiling mode. The killer feature for me was that you (the user) define frames on the desktop, and then windows are placed into frames rather than resizing and re-jiggering everything whenever a new window opens.
I ended up writing my own WM instead: https://github.com/BurntSushi/wingo
https://github.com/BurntSushi/toml
It's a hybrid WM with first class support for normal floating windows (the default) and first class support for tiling. However, it's also designed for multiple monitors and therefore breaks a couple chosen EWMH standards, so your favorite pagers may not work in a multiple monitor setup.
- My workspaces were monolithic. If I changed my workspace, the windows on all my monitors went with it.
- Alt-tab worked globally across all monitors. I wanted it to only list the windows that were on the currently focused monitor.
- Moving windows from one monitor to the next in a predictable way was a chore. (I eventually resolved this with some key bindings, but it was a hack.)
- No window manager I know of afforded me the option of using tiling or (GOOD) stacking layouts on a per-monitor basis. (Some tiling WMs exist that solve the monolithic workspace problem, but they are all tiling.)
My first solution to this was to fork Openbox. It worked well for a while, but it was subject to a lot of state transition bugs and my hack became hard to maintain.
So I wrote my own. In Go. (Including a full X client stack.) https://github.com/BurntSushi/wingo
I love working with three monitors now, because I can freely mix and match the windows on my screen. My workspaces are dynamic (add/remove/rename as I please), so everything is composable. On one monitor, I might have a bunch of terminals in tiling mode. On another, I might have GIMP in stacking mode. Interestingly, in order to achieve this, I had to break compatibility with existing standards (but support as many as possible). As a result, some existing WM tools (particularly pagers and possibly task bars) just can't work well with my WM without explicit support. Perhaps this is why so few of these WMs exist outside the tiling world!
Me too! I wrote a window manager in Go[1] that I've been using for years now. I love that it takes <30 seconds to download and compile the whole thing. No C dependencies (compile or runtime) at all.
With that said, doing it with Rust should be almost as easy. There's no `cargo install` command, but I think it's only a matter of time. :-)
Your ideas seem cool, by the way! Sharing CSV data would be especially nice.
Of course, it's not all moonpies and pennywhistles. XGB only supports basic extensions like RandR, Xinerama, Render and Composite. But it's missing Xinput and XKB (which are monstrous).
(Wingo is a true hybrid WM. I like to describe it as "Openbox meets Xmonad.")
The solution (for me) was to throw out a spatial representation of workspaces and adopt a more dynamic approach. Instead of being fixed to a set of N workspaces in a particular geometry, I switched to having a fluid list of named workspaces. What makes this work particularly well on multiple monitors is that each workspace can be viewed on any monitor. So for example, with three monitors, I have three workspaces visible at any point in time. And yes, I can flip the workspace on one monitor to the other monitor.
This ends up being great for my work flow, since I can maintain my work area for any particular project without cluttering up the rest of my desktop. For example, when I'm working on the window manager that implements this functionality, I might have a workspace called "wingo" for code. And when I want to switch back to working on the X client library for Go, I go to my workspace "xgb" and it has me right where I left off.
And of course, I have workspaces like "browser", "mail", "irc", etc. I have some temporary workspaces too, which are used for scratch work.
Any workspace can be removed. And I can add a new workspace with any name at any time.
If you're interested, this is all implemented in my hybrid stacking/tiling window manager: https://github.com/BurntSushi/wingo
(Similar features exist in i3 and xmonad, but both are emphatically tiling window managers.)
Desktop applications are not very demanding. You can write them in scripting languages like Python or JavaScript, both has been done in Gnome. The libraries/toolkits are more demanding.
> Haskell has proven gc language is fast enough for a WM (xmonad).
https://github.com/BurntSushi/wingo
> However my original statement defined systems as kernel code
Rob Pike (one of the Go creators) seems to define it differently:
"We designed it to be a systems level language because the problems we do at Google are systems level, right? Web servers and database systems, and storage systems and those are systems. Not operating systems, I don't know that Go would be a good operating system language but I am not sure it wouldn't be, what was interesting was because of the approach we took in the design of the language, somewhat to our surprise it turned out to be a really nice general purpose language." http://www.infoq.com/interviews/pike-google-go
- Google is using it internally, where speed is an absolute requirement
- Vitess, recently open sourced (and used internally by youtube) would definitely have to be fast for the task youtube is using it for. (http://code.google.com/p/vitess/)
- Desktop window manager in Go that is very fast even on lower spec machines: https://github.com/BurntSushi/wingo
Just my two cents. I would absolutely stay away from node.js if you are in an environment where people touching the code aren't easily accessible, since it's very easy to write javascript that only you understand. The other languages seem to punish it a bit more, while at times it feels as if javascript embraces it.
If you like tiling and multiple monitor support, I suggest you check out Wingo. [1] It's a hybrid window manager written in Go, and configured in simple INI-like files.
Disclaimer: I'm the author.