QTile – An XMonad-like tiling WM written in Python(qtile.org)
qtile.org
QTile – An XMonad-like tiling WM written in Python
http://www.qtile.org/
24 comments
> - bug: QT applications leave withdrawn "empty" windows on the screen if qtile is reloaded (which happens when displays are connected or disconnected)
Late reply, but this might fix it:
https://github.com/qtile/qtile/pull/1807
Late reply, but this might fix it:
https://github.com/qtile/qtile/pull/1807
> 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.
(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).
Haskell isn't ideal w.r.t. XMonad (as it is compiled rather than interpreted) but I prefer it to Python as a language.
We'll have too see how this turns out in terms of libraries!
We'll have too see how this turns out in terms of libraries!
Qtile is great, for me the missing killer feature is the ability to have multiple top bars. It's close:
https://github.com/qtile/qtile/pull/1239 https://github.com/qtile/qtile/pull/1387
https://github.com/qtile/qtile/pull/1239 https://github.com/qtile/qtile/pull/1387
There's also bluetile, written in haskell
http://bluetile.org
Is that still in development or is it an abandoned project?
If curious see also
2014 https://news.ycombinator.com/item?id=8357944
2012 https://news.ycombinator.com/item?id=4770610
2014 https://news.ycombinator.com/item?id=8357944
2012 https://news.ycombinator.com/item?id=4770610
Is there any significant performance penalty using WM built in Python?
Take a look at the requirements.txt: https://github.com/qtile/qtile/blob/ecf216205ccfe72bbdee3183...
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.
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.
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
Couldn't really imagine there being any. WM events are few and far between, and are hardly constrained by single thread performance.
Curious how the garbage collector works.
I used a Go-based window manager called Wingo for quite a while and never noticed any performance issues.
Go is also fully compiled to native code, big difference.
But it's still garbage collected. And GC should be done by the python interpreter proper, so it would be in native code.
A tiny portion of Python's total execution time.
Don't get me wrong; I expect Go to be far more performant than Python. Just, they're both garbage-collected, and I have no reason to expect GC perf (specifically) to differ.
Which just shows that learning about GC algorithms is a must.
http://gchandbook.org/
And the differences between value types, AOT compiled code execution, bytecode interpreters and FFI marshalling costs between bytecode interpreters and native libraries.
http://gchandbook.org/
And the differences between value types, AOT compiled code execution, bytecode interpreters and FFI marshalling costs between bytecode interpreters and native libraries.
What does this have in common with the Qt framework? Asking because the project name follows the naming convention for Qt classes and widget.
Now that is an interesting backstory. I doubt I will ever see any proof for it due to its nature, but it's a curious anecdote nonetheless!
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)