Way back when, I had a little trouble installing Qtile on Ubuntu 10.10 or so, so I wrote up a little guide on how to do it. I think that became part of the official docs somewhere along the way? But anyway, I didn’t think much about it.
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.
Oh my god, that was me! I can't believe I just read this on HN. Whenever I'm at a conference (usually PyCon or DjangoCon) and meet someone whose work has benefited me, I try to make a point to thank them.
I ended up getting involved with Qtile for a few years and contributed to the docs, website, and various widgets.
> Additionally, I disagreed with the default way of installing Qtile. As a principle, I never sudo pip install anything. Instead, I asked my friend Karthikeyan Singaravel, who is a Python core developer, and he recommended using the deadsnakes PPA for Ubuntu to install any version of Python that I chose. I tried compiling python 3.10 myself, installing to /opt/qtile/ using configure --prefix /opt/qtile/ during the configuration stage of the source code. However, I admit that using deadsnakes is a far better idea since I could create a virtual environment based on python3.10 into /opt/qtile/ instead. I had to change the owner of the folder to my user account. Note that I could store the virtual environment in my home folder and just use that, but I wanted to isolate this outside of my home folder.
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?
> 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.
> 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.)
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?
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.
> You _can_ use a venv. I prefer a dedicated environment for this.
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.
> 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.
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.
My reply here is to people reading along. I know you know this stuff.
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:
Now if you run `pip install foo` in that shell, it'll install the package inside that virtualenv. If your code has `import foo` somewhere, it'll load the virtualenv's package, no matter what versions of foo are installed elsewhere. It's nearly identical in concept to Node's ./node_modules directories, except that you have to explicitly activate the virtualenv, which also gives you the flexibility to easily use the same venv for multiple projects if you really want to.
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.
That’s totally a thing you can do, but I don’t think it gets you anything at all over just using the built-in virtualenvs. (Although lots of people create them with uv or mise or poetry or whatever, the feature is part of Python itself, and all those tools do is create and configure them for you.)
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.
I've been using qtile as a replacement for hyprland for a few months now, and I don't have any complaints at all. It's an extremely functional piece of software, and at least for me it seems to be more stable than hyprland was.
It's so out of the way isn't it? I have to switch to using a Mac for work and I can't get the Aerospace filing window manager to work like Qtile does. It's a shame.
On that note, is there any good window management paradigm on MacOS? Tiling just doesn't seem to work well tacked on compared to full-fledged i3, and MacOS' seperation of applications from their windows makes multi-tasking a giant pain. Windows is miles ahead in this regard, and Linux of course offers options for every paradigm imaginable, so it leaves MacOS feeling particularly mediocre.
blast from the past. I moved over from awesome to qtile as I really didn't use lua probably a decade ago (and I still don't) but unfortunately, over the years, I did the boring thing and just stuck with the gnome 3 default installed by whatever distro I use.
Does qtile work on fedora these days? Good to hear wayland support is coming along, I often miss tiling wms.
Not sure about QTile but I'm using swaywm on Fedora 43, it's a delight to use! I am using a mix of sway and hyprland utensils for everything and I couldn't be happier. Wayland on Fedora is a no-brainer, fixed so many annoyances after moving from X.
It's great to see Qtile still going strong. I used it briefly many moons ago, and enjoyed how easy it was to extend, given it is configured with Python. Sadly, I experienced crashes, which soured the experience, and moved on to bspwm, and now niri.
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.
reply