FWIW, I've been using qtile for several years now, switching from awesome.
Nice things:
- tiling WM with support for floating windows
- useful widgets out of the box (CPU/mem/network graphs, clipboard notification, audio volume)
- works well most of the time
- highly configurable and scriptable
- you can set the active group ("virtual desktop) for each screen individually, whereas awesome has virtual desktops that cover all screens at once. This is great for lectures/talks as I can prepare contents/applications on my laptop screen and then move this group to the to the projector screen when needed. This makes switching between slides, web browser, or a live demo easy.
- completely written in Python, so one can easily modify the source code and reload qtile
Annoying things:
- sometimes my X server crashes and I suspect qtile to be at fault. However, it happens rarely enough so that I did not bother investigating further.
- the interactive Python shell for qtile (qsh) is a strange mix of Python and filesystem metaphors with too little actual control over the WM
- documentation and examples are not always up to date
- bug: QT applications leave withdrawn "empty" windows on the screen if qtile is reloaded (which happens when displays are connected or disconnected)
- dynamic multi-window applications don't work particularly well with tiling WMs (if these don't recognize all windows that need to be floating)
- applications can only be in a single group / virtual desktop. This is an inherent limitation caused by the aforementioned ability to assign groups to individual screens (you obviously can't have the same X11 window to be rendered to two different screens at different dimensions)
> - bug: QT applications leave withdrawn "empty" windows on the screen if qtile is reloaded (which happens when displays are connected or disconnected)
> whereas awesome has virtual desktops that cover all screens at once.
(disclaimer: Awesome co maintainer here)
I am not sure what you mean. Awesome tags are per screen and can be moved to other screens (since pretty much day 1). Can you be more specific? In any case, I am slowly adding support for Xmonad style "shared" tags across screen, so I am collecting comments/use_cases on how to make tags better.
I've been wanting to try it for a while, but I'm just happy enough with i3 that it's hard to put in the time switching to something else. One thing I tried at one point and really liked in, IIRC, xMonad, was the idea of a "focused" window and then an LRU stack of windows behind that. I really liked that idea for the little bit that I tried it, but I found the configuration otherwise to be impossible to use (for me).
All the heavy lifting is offloaded to C libraries. So, no, you shouldn't see a significant performance penalty, unless your Python WM is doing bitcoin mining in the background or something.
It's a WM (Window Manager). It only sets the placement of windows, it does not interfere with the programs themselves (that's what systemd and gnome-session do) nor does it do the fancy part of the painting (that's what a compositor does).
So no, do not expect a significant performance penalty.
Having done tiling WM with lots of logic implemented in Lua myself, ten or so years ago, I never met any performance issues, besides repainting of dragging indicators for free floating windows
Nice things:
- tiling WM with support for floating windows
- useful widgets out of the box (CPU/mem/network graphs, clipboard notification, audio volume)
- works well most of the time
- highly configurable and scriptable
- you can set the active group ("virtual desktop) for each screen individually, whereas awesome has virtual desktops that cover all screens at once. This is great for lectures/talks as I can prepare contents/applications on my laptop screen and then move this group to the to the projector screen when needed. This makes switching between slides, web browser, or a live demo easy.
- completely written in Python, so one can easily modify the source code and reload qtile
Annoying things:
- sometimes my X server crashes and I suspect qtile to be at fault. However, it happens rarely enough so that I did not bother investigating further.
- the interactive Python shell for qtile (qsh) is a strange mix of Python and filesystem metaphors with too little actual control over the WM
- documentation and examples are not always up to date
- bug: QT applications leave withdrawn "empty" windows on the screen if qtile is reloaded (which happens when displays are connected or disconnected)
- dynamic multi-window applications don't work particularly well with tiling WMs (if these don't recognize all windows that need to be floating)
- applications can only be in a single group / virtual desktop. This is an inherent limitation caused by the aforementioned ability to assign groups to individual screens (you obviously can't have the same X11 window to be rendered to two different screens at different dimensions)