Hacker News new | comments | ask | show | jobs | submit login
A tiling window manager written in Rust (github.com)
325 points by TheHydroImpulse on Dec 17, 2014 | hide | past | web | favorite | 170 comments

I find it funny that it seems like any conversation about a particular tiling window manager will eventually turn into a conversations about window managers in general.

So to continue the trend, I used to use tiling wm's until I learned about Emacs. Emacs lets me do away with tiling mostly because it itself supports it in a way, namely C-x 2 and C-x 3. I can run all my shells and gdb's right inside Emacs. Nowadays I usually either have one fullscreened Emacs window, Firefox, 1 external terminal, and maybe LibreOffice open on my laptop. I don't mess around with moving them around and resizing them. For me, it's enough to simply have workspaces to manage all of them (I use C-M-[np] to switch back and forth through them, Caps Lock is remapped to Control).

It's true though that the benefits of tiling window managers isn't just the tiling itself, but often that they're programmable and configurable through plain text files. There's also the benefit of lower resource consumption if you run it bare.

As for what I actually use? Xfwm4 gets the job done.

I'll second using Emacs as the primary graphical shell. It shouldn't really be surprising that it's good for that task, since the interface is (or so it seems to me) heavily influenced by Genera's X interface. If Emacs let you display an external program such as Firefox in a buffer, I'd as well do away with Openbox and just run Emacs.

I wish use of something like Xembed was more pervasive. Being able to compose applications would be really nice.

Tiling for Emacs: http://www.emacswiki.org/emacs/tiling.el

(I use it rather rarely, because I have a small screen and generally have no more than 3 windows open at the same time; I jump between Emacs' "workspaces" with help of Elscreen)

OTOH I use urxvt with tmux for most command line stuff because it works better with zsh completions and colors and such. So I have three WM-level windows open (on separate virtual desktops, each maximized): urxvt, chrome and emacs with urxvt and emacs being further split into windows organized in a tiling manner. Works great for me :)

To add a little consensus, this is almost my exact setup too, though I'm on OS X and use Chrome for browsing.

As well as using C-x 2 and C-x 3, I've started using perspective.el (https://github.com/nex3/perspective-el), which means I can switch between different projects each with their own buffer set and window configuration, as well as switch to an IRC perspective. It's such a well-executed extension, definitely recommend it if you've never tried it.

Followed the link, found this:

> similar to workspaces in windows managers such as Awesome and XMonad (and somewhat similar to multiple desktops in Gnome or Spaces in OS X)

Similar to eclipse perspectives I'd say although it is hard to say from reading alone. Did I misunderstand?

(Also, why so few screenshots in the eclipse community? A few good images gives you a better feel without installing.)

I do this too, with workspaces on OS X and Windows (using VirtuaWin on Windows). Was always on a tiling wm on Linux before I switched to OS X (and now using Windows too a bunch), don't really miss them that much any more after starting to use emacs + evil.

Sounds like my exact setup, except I use Conkeror as a browser (it's an Emacs-like UI on Firefox's engine). I also use Xmonad as my (tiling) window manager, even though I usually cycle through fullscreen windows on various desktops, as you say.

Do you just install from source? Or do you use any of the debs? Which one? Are you on Debian or Ubuntu?

I use NixOS. In /etc/nixos/configuration.nix I added the line:

    services.xserver.windowManager.xmonad.enable = true;
    services.xserver.windowManager.default = "xmonad";
Then ran `nixos-rebuild --switch` to use the new config.

And xfwm4 has a great plug-in/patch available that enables tiling!

Once you have started to use a tiling window manager (Awesome WM in my case), you can't go back, it's just a huge boost of productivity for developers - especially when you come from OS X where dragging/resizing windows is a real pain.

shrug I've heard this argument many times, but this is clearly a different strokes situation.

I set my window layout up once at the start of a multi-hour working session. Most of the time, that's either 1) a large MacVim window and a terminal or 2) that plus a browser. It takes ~10 seconds to get it how I like it. After that, cmd+tab works just fine.

Even on my 27" display, I usually prefer to have a little overlap where all three windows rest in such a way as to permit the most relevant bits to be visible simultaneously, while allowing for overall larger space when an individual app is focused. Tiling window managers tend to distort windows to less than ideal proportions, as they strictly eliminate overlap. That said, I utilize splits (ie tiling) within vim to great extent.

Obviously it's personal, but the main issue I've always had with Alt-Tab is that as soon as you have more than 2 windows, getting to a specific application is now something you have to think about (or hit key, look, possibly hit key again). Since I'm often doing web development, I usually have a terminal open, an editor, and a web browser. Except for terminals, I pretty much always have everything full screen - the benefit is that Super-1 gets me to terminal(s), Super-2 gets me to my editor, and Super-3 gets me to the browser.

Just a quick tip on that note: In win7+, Win+N opens the Nth application you have pinned to the taskbar, counting from the left.

This is also true in Ubuntu's Unity, but after trying to use it, a minor issue drove my crazy: if you switch to one that isn't open it will open the application. So if I accidentally Super-4'd (which I didn't think I did, but after trying to use Unity for a while, I'd do it at least several times a day), it would start whatever the 4th application was. And then you have to deal with it showing up a fraction of a second later. I don't want switching and starting applications to be the same action, because switching should _always_ be extremely fast. If there was a way to make it only switch if it was open, then this would be a viable option for at least my workflow.

Thank you for reminding me. It's actually even better than that. Let's say your taskbar looks like this:

(1) Browser: pinned and now open (1 tab only). (2) Windows Explorer: pinned, open, several windows. (3) Windows media player, pinned, closed. (4) Notepad: not pinned, but open.

Win+1 will bring the browser to the front, unless it's already there, in which case it will minimize it.

Win+2 will bring a Windows Explorer window to the front, and if you keep pressing it will cycle between them.

Win+3 will obviously open Windows Media Player,

Win+4 will bring Notepad to the front.

I actually find that _worse_ than what the parent described. If I hit Win+1, I want to see the browser provided that it's open. I don't want the state of the system prior to hitting that to have any effect on it. If I accidentally hit Win+1 twice, it seems that I would end up minimizing the browser. At least for me, the primary value that tiling window managers provide (even though it has little to do with tiling!) is idempotency.

Even better:

Win + shift + number will start a new instance of the application in that taskbar position (multiple explorer windows, for example).

Win + shift + left/right will move the current focused window between monitors.

I find Win + Left/Right (makes the program use left or right half of screen, Win+Up for fullscreen) the best news in Win7+. This saves so much time and makes me hate all programs that do not support it fully.

They need numbers that appear there on the win key press, after icon number 4 I can't just look and get the app right.

I've come down to just using Terminator terminal emulator[1] (which allows you to open multiple sessions in the same window with a CTRL+SHIFT+E or CTRL+SHIFT+O) and a web browser. I used to care about which desktop I used (KDE or Gnome, etc) and how it was setup... but lately that just hasn't bothered me. As long as I can have 3-4 terminals open in the same window, and some browser, I'm productive.

[1] http://gnometerminator.blogspot.com/p/introduction.html

I work this in OS X by using Alfred (Spotlight would work too). It's just Cmd+space to bring up the search bar and then another another letter or 2 (v = MacVim) and hitting Enter to switch.

I find keyboard-driven grid-based window flingers to be Good Enough.

On OS X, that's SizeUp (or Divvy, ...) with a custom grid to suit my screen and then I never have to use the mouse to move/resize windows.

ShiftIt is a nice free alternative to SizeUp and Divvy.

Last ShiftIt release was in 2012. And it requires XQuartz for some reason.

On the other hand, Spectacle (also open source) is supported and it doesn't require XQuartz. That said, I don't like Spectacle default shortcuts (hard to remember for me and there's a conflict with Chrome switch-tab command). I now use http://spectacleapp.com, but with ShiftIt-inspired configuration:


Honestly, since I tried Amethyst [0] no other tiling WM for OS X has come close.

[0] https://github.com/ianyh/Amethyst

It's amazing how many of these things there are. Thanks, that's yet another bookmark!

I'm still using Hyrda with some simple commands, like moving window to the left half, right half, full screen, center.

Haven't tried the new version of Hyrda yet.

I find that "follow mouse" mode helps alleviate this pain a lot: when you can interact with a window (mouse or keyboard) without having to bring that window in the foreground, you end up moving windows around a lot less.

I like tiling in general but doing it well requires a big monitor.

I don't know, I run dwm on my 11" wide(ish) screen laptop, and it works for me, certainly better than a more traditional WM: generally, the less screen estate you have, the more it pays to make efficient use of it.

If I'm coding in Clojure, I have a vim window on the left, and a repl and a plain terminal (mostly for leiningen and git commands) stacked on the right. I could set this up in a traditional WM: but [a] it would take (a bit) more initial effort and [b] more importantly, with dwm I can temporarily bring in extra windows (e.g. a web browser) and then get rid of them again without having to restore my layout from scratch.

I agree with you about focus follow mouse (though it can be more trouble than it's worth if you have an overly sensitive trackpad).

Agreed in concept, but you can get similar if not greater productivity gains from stacking/floating WMs that let you move and resize windows into a tiling-like configuration. Examples are goomwwm and subtle.

This "manual tiling" approach is also probably the only viable option for tiling-like window management on OS X. While not nearly as powerful or productivity-promoting as the above-mentioned WMs or conventional tiling ones, the OS X program Spectacle (http://spectacleapp.com) makes life a lot easier on OS X for those of us who are used to the screen real estate and keyboard control afforded by tiling WMs.

Edit: Another commenter mentioned the non-free Optimal Layout (http://most-advantageous.com/optimal-layout) for OS X. I haven't downloaded the trial yet, but the website makes it look very promising.

I've used an xmonad clone for osx [0] for about a year now. It's a lot buggier than xmonad - mostly due to osx's terrible apis - but it gets the job done.

[0] https://github.com/ianyh/Amethyst

Recent versions of Amethyst https://github.com/ianyh/Amethyst have made a pretty much xmonad-like experience on osx. There are a few quirks but I don't see me going back at this point.

I've never worked in a situation where I could use a tiling window manager (OS X here), but I've always wondered how that's supposed to work when my normal workflow involves opening and closing a lot of windows. Especially terminal windows. I open throwaway terminal windows all the time, and then close them if I'm done with them, or keep them open behind my other windows if they have some information in them I need to reference later.

Often when I'm done working, I end up closing perhaps a dozen scratch terminal windows.

Tiling window manager users typically avoid transient windows in much the same way that modern browser users avoid transient browser windows.

For instance, my primary development workspace has four columns: three emacs and one terminal with tab support. I don't open/close new emacs windows or new terminal windows, in the same way that I don't open/close new browser windows: I just use tabs within a single window. Likewise, I use multiple open buffers within my emacs windows, and multiple tabs within my terminal windows. If I need a transient terminal, I switch to a different tab or add a new tab.

Opening/closing transient terminals is pure UX overhead, IMO.

Terminal multiplexers like screen and tmux are a nice alternative to tabbed terminals. They cut down on screen clutter (no need for tabs, scrollbars, etc.) and have the added bonus that they remain running in the background, even accessible over SSH.

(I accidentally killed my X session this morning; everything in tmux survived :) )

I use transient browser windows all the time. I try and group related things into tabs, but a page I just want open for a second usually gets a new window. It's easier than navigating the flat tab list.

Optimal Layout[1] works pretty well as a tiling window manager (or close enough) for OS X. I've been using it as an essential part of my workflow for 2+ years. I also make heavy use of emacsclient and tmux[2] sessions and windows in conjunction with iTerm2[3].

When I have some time to experiment, I'd like to look at replacing Optimal Layout with mjolnir[4] or one of the similar tools listed in mjolnir's README, under Mjolnir vs. other apps.[5] Amethyst[6] looks like another option worthy of consideration.

[1] http://most-advantageous.com/optimal-layout/

[2] http://robots.thoughtbot.com/a-tmux-crash-course

[3] http://iterm2.com/

[4] https://github.com/sdegutis/mjolnir

[5] https://github.com/sdegutis/mjolnir#mjolnir-vs-other-apps

[6] https://github.com/ianyh/Amethyst

Optimal Layout looks interesting. I'll have to give it a shot.

Another one you might want to look at is Witch[1]. I've tried it before but it never really "stuck" for me. Maybe I should give it another shot. Witch isn't a window manager though, it's only concerned with making it easy to switch between windows rather than laying them out.

Why do you use iTerm2? I've looked at it in the past, but it just feels non-native enough to bug me. I know they advertise tmux integration, but the one time I tried to find out what that actually entailed, it didn't seem to work for me (though I've been told it basically just uses iTerm2 native splits in place of tmux splits).

[1] http://manytricks.com/witch/

I checked out Optimal Layout. It seems possibly useful at first glance, but I already had to disable it, because there's no way to turn off the keyboard shortcuts while in specific apps, and I need to have the keyboard shortcuts disabled while in World of Warcraft.

I started using iTerm2 some years ago. I tried the built-in Terminal.app again earlier this year, just to see if it would work for me, and couldn't figure out how to easily "fix" the keyboard input so that terminal-mode Emacs works as expected, with respect to key sequences involving meta. iTerm2's preferences panel makes the same "fix" quite simple, so I'll be sticking with it for the time being.

Terminal.app doesn't quite have the right default set of bindings, but iTerm2 also has some wrong bindings around the meta key.

If you want to enable option-as-meta in Terminal.app, you select the Profile you want in preferences, go to the Keyboard tab, and there's a checkbox at the bottom. This is also where you can customize the bindings for various key sequences, if you think they're wrong.

There are plenty of apps that provide varying levels of window-manager functionality to OS X. I would try a couple out and see if any seem useful to you.

http://manytricks.com/moom/ http://mizage.com/divvy/ http://ianyh.com/amethyst/ http://spectacleapp.com/ https://github.com/fjolnir/xnomad https://itunes.apple.com/us/app/bettersnaptool/id417375580?m... https://github.com/sdegutis/mjolnir

Using two monitors on Linux and running XMonad changed the game for me. Very organized, productive and efficient interactions with the system grew organically out of it. Even though I tend to use KDE (and KWin) these days on a laptop, that experience helped me drill down into a workflow that I apply anywhere I can. The best thing is that, everybody comes to their own "most efficient" workflow using these tools. Interacting with OSX/Quartz after that felt something akin to giving up <insert code editor or IDE of choice here> and writing all your code in [TextEdit.app | Notepad.exe | nano].

Also, scratch terminal windows are solved by TMUX and a single terminal.

wtftw is very interesting. I can't wait to give it a shot.

Terminal.app supports tabs, I'm not sure why tmux would be any better (well, tmux can do splits, but transient windows don't need splits).

The problem is if I create a tab, I want it to be at least somewhat related to the other tabs in the window. And even then, I usually use new windows for scratch terminals because I want to see multiple different terminals side-by-side. I could use a vertical tmux split except that shrinks the original terminal, and I want both the original and new terminal to be at their natural size.

TMUX is a transferable implementation of terminal session and "tab" organization. It's also scriptable if you aren't happy with some aspect of it's default presentation or interaction. For me, that is enormously valuable.

Sounds like your use case could be mapped by TMUX windows acting like Terminal tabs, and TMUX sessions acting like multiple Terminal windows. Except the benefit is that now you can use this workflow on any system with a posix compliant shell and a tmux binary (which I'm pretty certain is practically all the things at this point). Sessions and windows can be given labels which is a nice touch too.

If you are an Emacs user, it's also worth noting that TMUX totally works well with ansi-term. :) I normally have a TMUX session dedicated to an ansi-term buffer in Emacs. Even if I have iTerm or Konsole using another session.

"..but transient windows don't need splits"; well, in my universe transient windows are splits. :)

Anyway, I don't want you to think I'm trying to persuade you into adopting what I consider awesome and useful. Just clarifying my statement. It sounds like you already have a workflow, are happy with it, and don't see any need for alteration.

I use tmux over mosh on my Linode. I've just never found it to be particularly useful on my local machine. Especially because it removes the ability for my terminal to manage history and requires using a keyboard shortcut in order to scroll backwards in history.

I believe Terminal.app handles mouse events differently, so the standard tmux config doesn't work right. Maybe see if https://bitheap.org/mouseterm/ improves matters for you.

Terminal.app doesn't handle mouse events at all. I filed a radar for that a while ago. But I don't consider that good enough reason to use iTerm2 as the programs that actually support CLI mouse events are very rare.

I just use Slate to snap window to left or right. It's not quite like tilting wm but it works quite well. I have no problem with it. And I do use Emacs, so there wouldn't any problem of splitting with those either. The only thing I miss from tilting wm is its minimal an simplicity. I used to use arch linux with dwm, configuring, patching creating shortcut just take a few line of code here and there, love it :)

My issue with tiling WMs is that there just isn't enough room. I use vim splits in a full-screen terminal but can only fit 2 columns comfortably. I can pull off 3 but then I can't see the full 80 characters in each.

I thought OSX autosized everything. I have never used it personally.

I really, really, really want to move to using a tiling window manager. Watching YouTube videos of people using them well, you can't help but think "Damn, they're really crazy efficient". But I can't find one that has good enough documentation that I can learn it on my own (and since nobody else at my office uses it, somebody has got to be first.)

I'd love to get into http://i3wm.org/ but can't find anything to push me over the ledge, so I keep resigning myself to checking out projects like the one in OP and thinking "Wouldn't that be nice..."

I've been using them on and off, and the first thing I'd like to mention is that they're in no way magical -- both when it comes to using them (which is mostly knowing a few shortcuts and internalizing the layout system), but also in regard to how much they help you.

Sure, they certainly do look snazzy, especially when coupled with the movie hacker-approved unified dark color scheme. New windows pop up and quickly assume their rightful space and everything just looks so darn tidy.

But for certain usage patterns, that doesn't get you a lot. Even if you're popping up disposable shell windows left and right, you might also do that within screen/tmux, where the window manager doesn't come into play at all (or have some drop-down quake-like console). Also, your running applications and especially their different configurations might not change that often, in which case you're really saving yourself some manual layout fiddling once. So a lot of people would perform pretty much the same with just alt-tab window cycling and virtual desktops (which seem orthogonal to the whole deal).

I mean, if you look at the vast majority of screenshots, you don't even see that much work. The obligatory IRC client, fake-GUI music players and/or file managers and probably an editor with the configuration file or some minor coursework open. It's not exactly Scotty and his Mac Plus.

Having said that, I'd add my vote to i3wm, as it isn't as ideologically pure as some others (you still have window titles if you want them, and the layout remains somewhat manual). Plus a rather readable configuration format, even if the default configuration is seemingly intended to drive vi-users mad.

My alternative would be bspwm, the binary space partitioning wm. A lot more minimal, but the automatic layout algorithm is rather tractable and one certainly wouldn't be confused with too many options.

Having said that, I'd add my vote to i3wm, as it isn't as ideologically pure as some others (you still have window titles if you want them, and the layout remains somewhat manual). Plus a rather readable configuration format, even if the default configuration is seemingly intended to drive vi-users mad.

I like i3 a lot, but even as an Emacs user the first thing I did was to change the focus key bindings to something vi-like. Using JKL; instead of HJKL on anything meant for Unix users just seems devilishly perverse.

> I mean, if you look at the vast majority of screenshots, you don't even see that much work. The obligatory IRC client, fake-GUI music players and/or file managers and probably an editor with the configuration file or some minor coursework open. It's not exactly Scotty and his Mac Plus.

Well, this applies to all WM screenshots ever, not just tiling window managers. The main problem with WM screenshots is that you want to show how it looks, show off some features, but my actual work is generally spread across many virtual desktops, each with just a few windows (mostly xterm)

Quite a lot of screenshots do cover more than one desktop, plus often a "clean" shot to show off the otherwise covered minimalistic and/or anime background pic.

I blame it more on the fact that many of the tiling wm crowd are quite young and don't do that much actual work with their machines, especially if they just switch to Linux because of other screenshots of said style.

Or just not being able to show e.g. proprietary codeā€¦

I'm "quite young" (26), although I don't know what you'd class as "actual work" (do Web development and PhD research count?).

To be honest I like using tiling WMs because they're not magic, whizz-bang things. I could lay out my windows better with a stacking WM (eg. when badly-behaved apps make assumptions about their size and put buttons off the edge of the screen), but a tiling WM does just well enough that I really don't care about my window layout anymore. Whatever Xmonad does is usually fine.

Likewise, with a tiling window manager I really don't care about background pictures anymore. Before using tiling WMs I used to use chbg to cycle through a directory of images, and use (fake, then composited) transparency in terminals, etc. These days my machines boot straight into Xmonad with st and emacs open; my only "background" is a black screen for a couple of seconds while they start up.

Any screenshot I take would just advertise whatever fullscreen application I have open at the moment, along with a line of text at the top of the screen with a clock and counters for my unread email and failing tests.

> I'm "quite young" (26), although I don't know what you'd class as "actual work" (do Web development and PhD research count?).

Certainly. It's always hard to judge age on the 'net, but looking at the relevant discussions on reddit or linux forums, you'll find an astonishingly uniform spread of applications, and if you find any code that's not the configuration of the window manager, it'll be some kind of programming 101 material. This, along with the "just installed Linux, this is my new awesome desktop" makes me a bit biased towards assuming a large quantity of teenagers -- also more likely to generally proactively show their neat desktops.

This doesn't mean that every tiling wm user is that way (I certainly am not), just like pinterest isn't a good indicator about the prevalence of refurbished palettes in American bedrooms...

I would say that you probably have more in common with corporate windows users who have their apps running fullscreen all the time, too and that way don't ever changed their backgroudn from Napa valley, than with the "unix ricers" who regularly apply patches to their minimal wms that leave large borders around their windows, so that their background is still evident.

    My alternative would be bspwm, the binary space partitioning wm.
I like bspwm's approach to keyboard shortcuts: don't do them. Have an external socket through which external applications have complete control over window-manager tasks, and use an external hot-key manager (sxhkd, by the auther of bspwm) to send commands to it to handle windows.

Tiling managers become more compelling on large high resolution displays where running everything maximized is inconvenient and you want to ease the burden of shuffling windows around.

> But for certain usage patterns, that doesn't get you a lot. Even if you're popping up disposable shell windows left and right, you might also do that within screen/tmux, where the window manager doesn't come into play at all (or have some drop-down quake-like console).

I've started to notice I often have i3 open with an xterm running screen in which I'm running vim with multiple buffers. I should start using ctrl-alt-F* so I have 4 layers of context switching...

I use StumpWM, but it can be a real pain in the ass to get running and configured. I like that it has static layouts: you manually split the screen into panes and windows go in those panes, rather than everything resizing & shuffling whenever you open a terminal. I also really like the keybindings, which are by default all preceded by C-t, so you'd hit "C-t c" to open a new terminal--this avoids the whole "window manager ate all my alt-key combinations" problem you'll run into with i3 and a lot of other WMs. The problem is that it's Common Lisp, so the binary is huge and it takes a long time to start up, and sometimes it crashes in interesting ways. But on the other hand, it's Common Lisp, so you can connect to it from Emacs and play with the code... at least until you crash it.

I'm thinking about trying the new Guile window manager that popped up here a few days back, it looks like it has a StumpWM-esque style and maybe Guile is a little more light-weight/less flaky than most Common Lisp implementations.

> I'm thinking about trying the new Guile window manager that popped up here a few days back, it looks like it has a StumpWM-esque style and maybe Guile is a little more light-weight/less flaky than most Common Lisp implementations.

Thanks for bringing this to my attention! I'm a StumpWM fan too and it looks like Guile-WM has promise. Here's the homepage for anyone else interested:


I was just about to switch over to Guile-WM on my desktop today, but it doesn't look like it has virtual desktop support, which kind of kills it for me for the time being. Otherwise it ticks pretty much all the right boxes.

Virtual desktops are so amazingly useful that it's hard to imagine why a tiling WM wouldn't adopt them.

I imagine he just hasn't implemented them yet--they're not incredibly difficult and can usually be added later, as I did for Plan 9's rio WM at some point.

I'm a fan of i3wm. It has fairly good documentation (I learned it on my own, primarily from the documentation), and a relatively active irc channel.

The nicest things about a tiling manager? You can control nearly everything from the keyboard. It's very quick and easy to set up side-by-side windows (or side/top-bottom, and so on), and resizing one automatically resizes the other. It really helps on smaller screens, since by default everything is full screen with minimal window decoration.

Some nice features of i3wm in particular - well developed manual control, most layouts can be expressed as the composition of simpler layouts, and the config file is just a config file, not a full fledged program.

Also, it's worth remembering that on Linux you can have multiple WMs installed at the same time. You can log in to i3wm, and if there's something you really can't figure out, you can log out and switch to gnome/kde/etc. I don't know if there's a way to switch WMs without shutting down the whole x session though. Would be interested to know if it's possible.

> I don't know if there's a way to switch WMs without shutting down the whole x session though. Would be interested to know if it's possible.

Some WM's support the '--replace' flag (Both the WM being replaced and the one you're starting have to support it). If you run a new WM with the '--replace' flag, the old WM will shutdown and the new WM will take-over all the windows it was handling. This is only switching WM's though, so you can't really switch into Gnome or KDE doing this and then switch-out. i3 doesn't support it though (It would have a bit of a hard time supporting it anyway), so you can't do it with i3.

If you can't do it that way though, then just have your X session start a terminal on screen instead of a WM. The X session will stay live as long as that terminal stays open, so you can start and kill any number of WM's as you want as long as your other programs don't mind it. Not everything shuts down very cleanly though, so you might not be able to start and close Gnome and then start KDE in the same session. You should be able to kill i3 and start openbox or xfwm though, for example.

> You can control nearly everything from the keyboard

Personally I'm still waiting for a tiling WM with mouse support - having used a few keyboard based WMs, and having used Eclipse, I find Eclipse to be by far the nicest. The only problem being that it's an application panel manager, not an X windows manager :(

The features I want from a WM: http://shimmie.shishnet.org/v2/_images/ae13a6ed6a5d725f34d10...

Ok, for the dragging part I would have to come up with something, but theoretically, your desired features are possible. I just need some spare time to implement the layout plugins and come up with a good way to handle keyboard shortcuts in nested splits.

kwin is working on this. They ripped the tiling logic from the core somewhat recently but I believe they either added it back as an addon, or are in the process of doing so. You can email their ML for more info.

i3wm lets you resize both floating and tiled windows via the mouse. You can also decide where the systembar goes.

I use awesomeWM, http://awesome.naquadah.org/, we have about 10 converts in our office now. It seems to be fairly well documented and has plenty of addons to make it look better (although I use just the bare minimum).

I just wish I could find a decent tilinging manager for OS X (divvy and amethyst do not fit my requirements)

I tried awesome, and was somewhat disapointed by a community that felt 'dead'. Searching google for answers to questions I had often yielded old, out-of-date answers not relevant to the current version. I did however appreciate the ease of configuring it with Lua.

If I feel like trying a tiling wm again, I think I'd go with xmonad. From reading, it seems to have decent defaults, and it'd a good opportunity to start playing with Haskell.

I wish integrating tiling wm's with regular DE's, even lightweight ones (lxde, xfce) would be more popular. When switching all out to awesome, I missed the conveniences like a tray with wifi and sound volume. I just want a DE, with tiling windows!

If you're running Ubuntu then if you

  apt-get install xmonad gnome-panel
a GNOME with Xmonad option will appear in your login screen. Then you have to create an xmonad configuration that works with GNOME like so

  import XMonad
  import XMonad.Config.Gnome

  main = do
      xmonad $ gnomeConfig
in .xmonad/xmonad.hs and everything will work.

Mind = blown. That's awesome, I'll have to give this a try. I used to run XMonad on Arch, but then I switched to Ubuntu a couple of years back and got with the Unity program. But if I can have the best of both worlds, I'm sold. The icing on the cake would be if a drop-down terminal like Tilda still works with this hybrid setup as well.

I've been using xmonad for ... well, guess it's been the past 3 years now. Never had to change the config or adapt to API changes as I had with LUA and things just work. Plus, it's quite performant (although it has some input-looping related quirks sometimes) and hardly takes up any memory. Can only recommend it to people new to the tiling wm scene.

I used Enlightenment 16 in Gnome 2 for years, but Gnome 3 seems to take more of an everything-or-nothing approach. These days I'm using Xmonad standalone, plus Xmobar as a kind of pipe-driven, text-only notification area. If I ever need a system tray, I run trayer (and curse whoever designed the program that requires it!).

There [0], how to use xMonad with xfce, I followed the instructions and it worked fine. I didn't have any problem to roll back either.


What about Amethyst didn't fit your requirements? I know it's still buggy, I'm just curious if there's any specific ones or if it's just generally not useful to you.

Try spectacle. It's pretty simple and straightforward. You cannot do advanced layouts, but splitting the screen in halfs both vertically and horizontally with the keyboard makes Mac OS X much more bearable.

I tried several for OS X and landed on using Moom [0].

The layout snapshots is really handy to jumpstart the day and put everything in place. Keyboard shortcuts allow resizing and moving windows around. It's highly configurable, so you can add or remove features as you see fit. I'd give the free trial a spin.

[0] http://manytricks.com/moom/

Same here, but I prefer a WM that supports (for want of a better term) "packing" 80 column wide Xterms and Emacs windows into the screen and doing static placement of things like Pidgin. The tiling WMs I've briefly looked at all seem to re-size windows to fill the available screen real estate; I'm old school and want my Xterms and Emacs windows to be 80 chars wide.

Are there any tiling WMs which support this layout style or can be easily configured to do so?

I use i3 and I love it. You can steal from my config if you like:


Mate... I will tell you that the one that I find have the easier learning curve is AwesomeWM.

The main advantage of it tho, is not the tiling window managing facilities... But the run-or-raise plugin.

It allows you to run (start) or raise (go to the window) of any application with an assigned shortcut.

Mine are: Mod+e - Emacs Mod+u - Browser (Conkeror) Mod+y - Browser (Chromium) Mod+k - Konsole Mod+. - Keepass Mod+x - Pidgin chat window Mod+i - Skype chat window

The choice of shortcuts may seen arbitrary, but I'm a Dvorak user and all the keys are easily accessible.

With this setup, from my editor I'm a Mod+u / Ctrl+g g to a search on google, and from there I'm a Mod+k from my terminal (from where I run tmux... ;P) and a Mod+e from Emacs.

I'm also using a dropdown terminal with another tmux where I have access, from any where on my system just pressing F1, to my MTA (mutt), file manager (mc), IRC (irssi), Music player (cmus) and a root shell.

Honestly... With this setup there is definetly no going back... Every thing on the tips of my fingers... Some shortcut away.

I almost feel part of the machine! :)

I use i3 since about two months.

I got same issues like you and here's my advice: install i3 and try to use it, after 2-3 days you'll be able to move windows, switch them or run apps with only keyboard (keybindings are pretty intuitive, but you need to try). Don't try to use it for every task or force yourself to use only it - I hate it when have to deal with some windows apps in wine, which are opening alerts and windows like shit, and then simply switch to gnome or sth. Don't try to customize everything at once, but rather slowly find your real needs and google around how to make your system your best tool.

I use I3 and highly recommend it. I used to use Awesome - i3 has felt much easier to work with and configure. The docs are pretty good.

I can't go back to a non-tiling manager now!

Do i3. It's one of the easiest to learn and the only way I was able to get into tiling window managers. I outgrew it when I got a 4K TV as it wasn't able to handle it well, but as others have said, it's "less pure" of a window manager. It's extremely dynamic, easy to move things around, and easy to resize. If you've used vim before it'll be even easier.

I used to use xmonad, but ditched it because it wasn't working well with Android Studio. I read somewhere that other tiling window managers have problems to display Android Studio under some video drivers.

Now I'm back to the default window manager of xfce4, which is ok since I tend to use only emacs and a browser, so I have have one workspace for each.

There is a problem with tiling window managers and Java GUIs. The fix is to export an environment variable whose name you can find on the XMonad faq.

Thanks for the tip! I gonna give xMonad another chance!

There's a program called "wmname" specifically designed for this: http://tools.suckless.org/wmname

Just run "wmname LG3D" then restart any open Java programs.

LG3D is "Looking Glass 3D", a Java window manager http://en.wikipedia.org/wiki/Project_Looking_Glass . It's quite amusing that Java's UI toolkit contains special-cases to avoid breaking their demos.

I like i3 quite a bit. It was easy to pick up and a huge improvement over KDE for what I do. Especially on the laptop. The 3 second X startup is nice too. It did take a little work to get it set up and comfortable.

I'm running i3wm.

I wouldn't consider myself an expert and found the change (I'm otherwise a Gnome kind of guy) easy enough. Is there anything specific you have trouble with?

It took me an evening to get fully switched to i3wm. It's simple, and fast, and easy to understand and configure.

I was in a similar situation and ended happy with bspwm beacause it's very minimal and simple to figure out.

i3 is pretty easy to learn and configure I'd say having dabbled with most of the popular window managers bar Xmonad. Nowadays I just use the Xfce window manager.

This is the sort of thing I hope to see a lot more of from Rust. Things that would traditionally be done in C/C++ moving to a new language with modern features. I'm very hopeful this trend will continue.

I thought tiling window managers were traditionally written in Haskell :-p

WMII, dwm, awesome, i3 are all written in C (and Lua).

He's making a joke about xmonad

The thing is, most languages can be used for writing a Window manager.

But since the alternatives to C and C++ kind of faded away from mainstream and they are anyway the UNIX system languages, most developers seldom look for alternatives.

With Rust, Go, D, Haskell, OCaml, .NET Native/Mono AOT, Java AOT compilers, hopefully developers will eventually realize that not everything needs to be coded in C or C++.

Most non-C languages also come with GC/managed runtime whether you want it or not. So for someone who don't want that Rust could be a fitting choice.

Today yes. Not so 20 years ago.

Modula-2, Ada, Object Pascal were some of the alternatives without GC.

These are the ones I meant by "faded away".

Last I checked the memory consumption of running xmonad (you know, written in Haskell) on my computer was a pittance; doesn't hog memory, and probably doesn't use enough memory to cause user-noticeable GC pauses.

Though if you're talking about applications in general, and not just WMs; yes, sure.

Yes it is more likely to be applicable to other apps other than WMs, but I also have integration in mind. So what if you want to write a WM like a library that can be used by whatever runtime a user may choose. Not sure that is a good idea but it sure would not be very portable if a GC must be carried inside the library. Memory consumption is not the only issue here.

If you were making a general point and not about WMs in particular, why didn't you say that to begin with?

Yeah, I've been using Xmonad for a couple years and it's just faithfully used very little memory and never crashed. Also, this is across 4-5 different laptops.

Most languages can be used for writing most things; however, for X11 window managers in particular, all of the APIs are exposed as C libraries, so the C family has a natural advantage. Other languages need an interface to those C libraries, a more idiomatic wrapper on top, and then a window manager can be written.

I've played with the Xlib libraries in Haskell and it wasn't the prettiest code I've ever written ;)

Not in the Go ecosystem. :-) We have a real, pure (concurrent) X client protocol implementation: https://github.com/BurntSushi/xgb (and of course, a WM: https://github.com/BurntSushi/wingo, which is hybrid tiling and stacking, kind of like Xmonad meets Openbox). /shameless plug

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).

When I saw this article, I thought "I bet burntsushi wrote it". I've been learning a lot from reading your Go code lately.

Heh, thanks. I spent years of my life with X getting my perfect WM. I'm happy to say I got there. But I can't stomach much more of X. :-)

I was actually looking for your code when I posted, but somehow forgot to refer to it in the end.

Good work!

This is what caused me eventually to move from Turbo Pascal to C++ during the Windows 3.1 time frame.

I started to get fed up with writing bindings to libraries not directly supported by Turbo Pascal and pure C was a no go for me.

I am a recent convert to C++ for the same reason (though not from Pascal but other high level languages like Prolog). I wrote my own Prolog interpreter with minimal footprint so I can still get an interactive prompt with a high level interface if I want to, but it is designed to be easy to expose C++ instead of the other way around.

Java AOT compilers

Java AOT compilers? What Java AOT compilers?

I know about Excelsior JET ($$$$) and gcj (abandoned). Do you know of any free and good Java AOT compilers?

I don't care if they are free or not. The point is that is technical feasible and they do exist.

Most commercial JVMs like IBM Websphere for Real Time, Aonix and JamaicaVM, just to cite three examples, do offer AOT compilation.

Java on IBM i mainframes is translated to the same bytecode used by C and C++ (yes I really mean bytecode not Assembly, IBM i has a kernel JIT).

Then you have RoboVM, CodenameOne, JikesRVM, SubstrateVM.

SubstrateVM is done by the same Oracle Labs working on Graal.

RoboVM is how LibGDX guys are targeting iOS.

And Oracle is changing the OpenJDK to eventually support AOT compilation.


Currently the only free on that might suit you, in case you only care about UNIX environments is RoboVM.

Thanks for taking the time to respond!

I'd love a Java AOT compiler that produces native binaries with no additional dependencies. (I'd even be okay if, as a side effect, some Java features were not supported, making it technically not-Java.)

For small tools and utilities, the JVM requirement is quite onerous, especially when one does not know if the end user has Java installed, or if they do, what version.

Alas, the company I work for will not budget for a Java AOT compiler, and for my hobby programming, the commercial Java AOT compilers are far too expensive to justify.

I'll just keep hoping a good and free (or inexpensive) Java AOT compiler becomes available some day. I would even donate money and/or code if a serious project started.

> For small tools and utilities, the JVM requirement is quite onerous, especially when one does not know if the end user has Java installed, or if they do, what version.

There some efforts in this direction with the OpenJDK.

As of Java 8 there is an application packager that brings everything together.


And the size of the native runtime has been reduced.


> I'll just keep hoping a good and free (or inexpensive) Java AOT compiler becomes available some day. I would even donate money and/or code if a serious project started.

If you are on GNU/Linux, Mac OS/X check RoboVM.


I sincerely apologize, I just now noticed you've answered my same query on other threads.

My understanding is that C++11 and eventually C++14 have plenty of modern language features. How does Rust compare?

A language is often not improved by adding features. Rust has a relatively clean slate (for now), which makes it a vastly better experience.

While they introduce constructs that significantly increase the safety of C++ written with them, they still have edge cases due to the C++ committee's commitment to backwards compatibility.

So while C++ is certainly improving, Rust has a fundamental advantage in the safety department.

Rust doesn't have C++98, C++ version "C with classes", and so on.

Less flippant answer; the usual arguments are that Rust is more memory safe, and hopefully less complex and with fewer gotchas compared to C++. It's still relatively complex - inherently, due to what it tries to do - but people seem to be of the opinion that it is much less complex than C++.

There is a tutorial by the author which goes into more details: https://kintaro.github.io/rust/window-manager-in-rust-01/

The first part is merely a rough setup. Tutorial is unfinished. At the moment I am writing my thesis, but I'll try to do a few parts over the holidays.

I think that's better to link to, instead of the code itself.

My apologies if this is a really naive question, I don't really do this kind of low level systems programming. Do most projects of this sort not have tests, or are they just hard enough that they don't really pay off?

As for the xlib stuff, I can't really write tests for that. But I will write a more extensive test suite for the core components, especially the ones in src/core.rs

For the methods in window_manager.rs, they often depend on the window system, but that shouldn't be a problem as I could simply insert a dummy interface.

Tests will follow. Last weeks were just filled with thesis and preparations for my last exam. So I used the coding for relaxation and kinda omitted the tests. I know, I know...behaviour.

> As for the xlib stuff, I can't really write tests for that.

I do that by wrapping the C APIs into traits. I have some macros that generate both the proper implementations with ffi calls and mock implementations. Then I can write extensive tests for the high level binding's low level behavior using properly set up mocks.

Can you tell how much `unsafe` code you used? And if you did, for what purposes?

Except for 2 exceptions, only for interfacing with xlib, as the calls to rust-xlib involve raw pointers (because rust-xlib is just a plain c-binding wrapper around xlib).

The 2 exceptions are: loading of the config library. The config file is compiled to a dynamic lib at startup, and I need to read the symbol out of that library to access the configure function. The DynamicLibrary module is unfortunately unsafe. The second exception is in one of the default handler methods, managing the on-the-fly restart of the WM (akin to xmonad). This involves a call to execvp in the libc:: module, and therefore also unfortunately requiring an unsafe block (split into 2 unsafe block, for pointer handling and calling).

Is it just me, or does Rust code always seem very clean and tidy? I haven't seen a Rust project yet where the code seemed "ugly".

It's such a pleasure to look at compared to C++ (though nested generics are still a pain).

If you want to see ugly code, you could look at the compiler's source code. A lot of code in it is clunky because it has evolved since Rust was a very young language, with gradual changes rather than full rewrites.

I agree, with the exception of to_string() and as_slice() all over the place when dealing with a lot of text.

to_string() will still be a thing, but many uses of `as_slice()` should be fixed by using &foo instead of foo.as_slice() in many cases.

Don't miss the tutorial at the end of the github page either:


Potential trend - instead of learning a new language with Hello World or blog/chat app, it's now via tiling wm.

It really leaves me shrugging my shoulders when I see titles like "such and such written in such and such language/framework". Like saying that writing a window manager in Rust (or whatever) is interesting just because it is in Rust.

Tell me, what does it bring to the table compared to other window managers ?

Writing a window manager in Rust is interesting precisely because it's written in Rust.

I wouldn't be surprised if this homebrewed WM didn't hold up in features or performance to alternatives like xmonad, dwm, Awesome, i3, etc.

However, the linked repo is an interesting way to showcase both a relatively new technology (Rust) and the innards of WMs, which most people don't look at very often. It gives non-Rust-users a glimpse into Rust's features and capabilities, and a glimpse at how simple (150 loc + 125 lines of config) a window manager can be.

I found it insightful.

> Tell me, what does it bring to the table compared to other window managers ?

This kind of window managers are often coupled to a programming language and the end user is expected to modify the source to their liking. For example, dwm is written in C, Xmonad in Haskell, awesome in Lua and there's even ones written in Scheme and Common Lisp. In all of these, the idea is that the source code is the configuration, and you're expected to hack on it.

Of course there's some appeal in just doing it in another programming language, even if it has been done before. A tiling window manager is a few thousand lines of code, so it's a neatly sized practice project.

So clearly Rust is ready for tiling window managers. When will Rust be ready for the web (at least to the level of where Go is right now) ?

The web ecosystem in Rust is still very early. There have been some awesome efforts recently in pushing a full-featured http library [0] (Hyper is now powering Servo [1]). The web ecosystem can't expand fully without a strong http library and previously, an unmaintained rust-http was used.

The next issue, if we're talking about high-performance http is asynchronous I/O which Rust doesn't currently bundle with (now that Rust has dismantled it's green threading runtime and is now sticking with native threading). However, mio [2], a lower-level Rust library in providing proper I/O abstractions that support async apis and the like is progressing pretty well.

The awesome part about Rust is that you have full control over the system. This allows one to build something like mio even though Rust doesn't support async I/O or a more efficient threading model, etc...

[0]: https://github.com/hyperium/hyper [1]: https://github.com/servo/servo/pull/4198 [2]: https://github.com/carllerche/mio

What makes you think that it isn't already?

Seems it's far from being mature enough to use in production - from a couple of sources including: http://arewewebyet.com/

What is it that makes writing an HTTP client so hard? It seems bizarre that a project like teepee could have been in active development for 8 months or more, and still not be anywhere near usable.

Well, http://github.com/carllerche/curl-rust has been working great for me. Sure, it uses libcurl so it isn't pure Rust, but that doesn't make it not work :-)

Teepee is mainly a HTTP server though - I can imagine that the HTTP client part of the library is more trivial.

This requires Xephyr, which is another window manager, running on top of X. What is the Rust part actually doing?

Xephyr isn't a window manager. It's an X display server that runs inside a window on another host X server.

Xephyr is just for testing. You can run wtftw completely standalone when you use it in your .xinitrc for example.

It's still a bit buggy though. Works perfectly fine here. Been using it as my default WM for 2 weeks straight now. But some bugs do seem to creep up on other machines.

That's just for testing.

If anyone else was confused about where the rest of the code is, https://github.com/Kintaro/wtftw-core

Author here. I am sorry about the confusion. It happened later in the project when I split it into 3 components (4 as soon as I add Wayland support). I should probably mention that in the Readme.

Thank you.

Is it really helpful to have different components of the same project in separate repositories? Are they really that independent? Four independent components for a single window manager seems a bit high to me.

Regarding modularization, I tend to prefer Fowler's criterium that a component should contain code which is usually changed together. So, if you have one component where 95% change slowly and 5% change often, you should split it. However, if you have two components that you almost always have to change at the same time, you should merge them.

That's why I split it. The window system interface is pretty much done. The main module won't change by much.

95% of the work is done in the core module. The main module is merely for the executable and rarely changes.

I've split it up because the xlib (and future wayland) modules need to refer to the core as a library, so the main module has nothing to do there.

Though I admit that part of the reason is earlier attempts with dynamic libraries, but that was more hassle than it needed to be.

I could merge the core back into the main module, but I'll wait a bit until I do that, just to be sure.

You could take advantage of having a single git repo for multiple cargo packages. This has worked extremely well for me. It was a lot easier having a single git repo to manage and control but still have separate packages for each of the different pieces. You could have the main package become the executable and have the core and various other packages in there, too.

I've seen this done in many Rust repositories on Git. I would also suggest to look into this (single repo, multiple Cargo crates in seperate folders).

Thanks, I will look into it. But tomorrow at the earliest. Today I'm out to celebrate the last ever exam I just passed.


And done

Wayland support

Wow, nice to see a tiling window manager working on that.

As soon as I figure out how to do that. But I need only minimal functionality, so I don't expect it to be _too_ difficult. I figured I should start with the Weston shell and figure it out from there.

loliwm is another one.


Say, which distro is that in the first screenshot?

The triangle logo is the logo of Arch Linux distribution.

I was being facetious. It's pretty clear they're running Arch; it says so several times in the image.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact