The Qtile Window Manager: A Python-Powered Tiling Experience
tech.stonecharioteer.com
tech.stonecharioteer.com
I went to PyCon in Santa Clara with a coworker who was being a little full of himself that morning. We were standing in the swag line and idly chatting with people around us. The guy in front of me was saying something, stopped to look at my name tag, and did a double take. “Whoa, you’re that kstrauser? Who wrote the Qtile guide? Wow, thank you so much!” He shook my hand, then we got our swag and went different ways. I don’t recall anyone else ever mentioning it to me, but from my coworker’s POV, we’d talked to about 10 people in a conference of 3,000 and one of them knew of me, so clearly I must be quietly famous or something. He stopped being a know-it-all, at least for the morning.
So thanks, Qtile. You gave me 20 seconds of fame while standing in line once.
I ended up getting involved with Qtile for a few years and contributed to the docs, website, and various widgets.
So, thanks again!
So, wow. You're very welcome, and I'm glad you had a good time with the project!
What a bizarrely tiny world sometimes, huh?
Wow.
I'm also kinda mind blown that a 15-second interaction I had at PyCon 13 or 14 years ago got a mention on HN. I only saw this post because someone at my local hackerspace told me that Qtile was on the HN frontpage. (I'm the resident Python champion and have shown off my Qtile setup at our monthly Linux night before.)
Small world indeed!
Qtile doesn't appear to be tied to a specific Python version. Could you not have made a virtual environment based off the system Python? For that matter, could you not have made a virtual environment from a local compiled-from-source Python? (I do that all the time, because I'm interested in testing against specific Python versions and comparing their performance characteristics.)
> Then, I changed the owner of the folder to my regular user account.
> Then, it was time to install qtile.
> I created /usr/share/xsessions/qtile.desktop and filled it with the following:
Doesn't this require the environment to be owned by root? Doesn't it make more sense to leave things that are in /opt as root-owned anyway? (Or at least, change them back after running the installation as an unprivileged user.)
> After this, I logged out of my previous window manager and switched to the new entry for Qtile.
Will any random greeter program just naturally pick up the contents of /usr/share/xsessions, then?
> Qtile’s config file rests at ~/.config/qtile/config.py
So does it just ignore all your other dotfiles? Can I safely just try this out regardless of my usual WM/DE choices?
I changed the permissions so everyone can run the binary.
You _can_ use a venv. I prefer a dedicated environment for this. I've been using Mise-en-place lately, it's great.
> Will any random greeter program just naturally pick up the contents of /usr/share/xsessions, then?
Yep. Your login manager will pick it up.
> So does it just ignore all your other dotfiles? Can I safely just try this out regardless of my usual WM/DE choices?
Yeah, you can. It's self-contained. I even setup ansible-based dotfile installation in https://GitHub.com/stonecharioteer/distributed-dotfiles.
While qtile doesn't care about the python version, I do. I've grown wary of environment clobbering, it's an issue that Python has had, one that even Ruby does better than it, I've discovered. I like isolating these, helps debug a lot. Now I have added more shortcuts to my config using Rofi scripts, I can see the Qtile log, access, the dunst notification history and other stuff easily with rofi. Give Qtile a go if you've been looking for a Tiling Window Manager. It's married to the Qtile Bar, though, but the Bar can do almost everything.
A venv is Python’s built-in way to handle dedicated environments. It’s what mise and uv use.
> I've grown wary of environment clobbering, it's an issue that Python has had, one that even Ruby does better than it, I've discovered. I like isolating these, helps debug a lot.
That’s a Python virtualenv. It’s had these for many years. I don’t know if there’s even any other way to get the same isolation with Python, short of using a container or something else at the OS level.
Also, pyenv and uv are wonderful ways to install whatever version you want without having to compile them locally, and you can have many versions installed at once and use a different one for each virtualenv if you want to.
You can, but you have to hack it together yourself, e.g. by modifying sys.path or setting up hooks that will do so (e.g. by creating a `usercustomize.py` or `sitecustomize.py` that gets pulled in by the standard library `site` module). And then it will amount to almost the same thing anyway, because there's really no reason for anything else.
The virtual environment itself is really barely anything at all: a place to put installed packages, and a `pyvenv.cfg` config/marker file that Python uses to automate said sys.path hacking at startup. Oh, and a bin/ subdirectory with symlinks (stub wrapper executables on Windows) to Python, and also a place to put entry-point wrapper scripts for the installed code. That's the main thing that isn't necessary for isolation, but it's pretty convenient. Oh, and some "activation" scripts that hack some environment variables together to make the environment easier to use (see, it's the use of those symlinks that determines whether the venv's packages are used).
The built-in support (such that `pyvenv.cfg` files are created and the Python binary directly cares about them) has existed since 2012, and its third-party basis (which automated the sys.path hacking in a somewhat more brutal way; https://archive.org/details/pyvideo_568___reverse-engineerin... is quite informative) since 2007.
Yeah, I can imagine hacking something together on my own if I had to ("first run `zfs create tank/myproject`...") but I'm glad I don't. I'm not referring to the person here, but I've seen people go to great lengths to avoid virtualenvs when they're about as lightweight as such a thing can possibly be. Like, this is the entire process for using one in a project:
$ python -m venv .venv
$ source .venv/bin/activate
If you have something like mise or uv, you can ask them to manage a venv for you, but they're conceptually just wrappers around those steps.
> Doesn't this require the environment to be owned by root? Doesn't it make more sense to leave things that are in /opt as root-owned anyway? (Or at least, change them back after running the installation as an unprivileged user.)
No, it doesn't require that, it just means your user-owned binary will be exec'd by root. But if you want the root -> user owned indirection, you can set `Exec=/etc/X11/xinit/Xsession`, which will exec your ~/.xsession as your user, and then you can keep a local install.
> Will any random greeter program just naturally pick up the contents of /usr/share/xsessions, then?
Ones that support x11 do, yes.
> So does it just ignore all your other dotfiles? Can I safely just try this out regardless of my usual WM/DE choices?
We try to read XDG_* things where relevant, e.g. themes and icons. But generally yes, once you point your xsession at qtile, we only use our config file.
Nothing as good as even native Windows sadly. Heck, even replacing spotlight is a pain.
Is it? I've found Raycast to be one of the greatest boosts to my productivity of any app on any platform. Then again, I was doing fine with Rofi + i3 before.
Does qtile work on fedora these days? Good to hear wayland support is coming along, I often miss tiling wms.