
A tiling window manager written in Rust - TheHydroImpulse
https://github.com/Kintaro/wtftw
======
spain
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.

~~~
sjolsen
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.

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

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

~~~
eridius
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.

~~~
jemfinch
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.

~~~
chriswarbo
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
:) )

------
ecaron
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/](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..."

~~~
mhd
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.

~~~
jff
> 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)

~~~
mhd
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…

~~~
chriswarbo
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.

~~~
mhd
> 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.

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

~~~
pjmlp
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++.

~~~
fspeech
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.

~~~
Dewie
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.

~~~
fspeech
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.

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

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

~~~
codingbinary
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.

------
jherdman
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?

~~~
codingbinary
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.

~~~
Heurtebise
> 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.

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

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

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

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

~~~
steveklabnik
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.

------
zobzu
The actual code: [https://github.com/Kintaro/wtftw-
core](https://github.com/Kintaro/wtftw-core)

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

[https://kintaro.github.io/rust/window-manager-in-
rust-01/](https://kintaro.github.io/rust/window-manager-in-rust-01/)

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

------
yoanizer
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 ?

~~~
rpedroso
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.

------
sgt
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) ?

~~~
zcdziura
What makes you think that it isn't already?

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

~~~
thinkpad20
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.

~~~
carllerche
Well, [http://github.com/carllerche/curl-
rust](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
:-)

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

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

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

~~~
codingbinary
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.

~~~
Symmetry
_Wayland support_

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

~~~
codingbinary
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.

------
0x420
Say, which distro is that in the first screenshot?

~~~
izacus
The triangle logo is the logo of Arch Linux distribution.

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

