Qtile TODO

TODO

new windows don't steal focus from prompt widget
  * make new windows stealing focus configurable
default config in /etc/qtile/config.py

The arbitrary Python code idea is pretty cool. Should it be able to interact with the qtile internals?

That's the idea, you basically say "here's a closure that takes a qtile instance", and it runs whatever. My motivation is for better switching between screens (e.g. if you have two stacks and you shift left off of the left most stack, it should go to the next screen). However, in theory, you can do anything with a handle on the qtile instance...

Wait, you're saying the memory leak has 100% been fixed?

Seems that way to me. I don't think anyone else has downloaded the code to test it out (which is unfortunate), but until I see more evidence of leaking, I'm not going to bother with it. If you see some, feel free to let me know, though!

I've been a bit selfish and been tanning Django tutorials :P

Also, I was a bit confused by what you were saying about your merging woes. It wasn't clear if we were supposed to be using the latest upstream patch or a merge that the qtile group should handle. I'd much prefer it if we could look into not using our own fork, possible? What exactly are we patching on our end?

The problem with me using something that's not in the repos means that I end up having to manage packages myself rather than leaving it up to pacman and that's just not cricket is it jeremy.

As far as I know, we still need xpyb-ng. As for what's different, we've had one guy install from upstream and, although his unit tests fail with what looks like xpyb vs xpyb-ng related errors, he says the WM runs fine (although I expect he'll get some crashes at some point). I too would like to stop maintaining this fork, but I haven't had time to push patches upstream.

Blegh.

Ok - let's run a diff against the upstream and our fork and see what's different and if the changes are fast-forwards?

Easier in theory than in practice. Go for it if you want, though :-)

Even a diff would be useful to know where we've diverged, tbh. You know? Even if it turns out that they won't accept patches and we really do need our own fork of it, then it's best to know where and what code needs to stay untouched vs upstream.

Feel free to look yourself:
git remote add freedesktop git://anongit.freedesktop.org/xcb/xpyb
git diff master freedesktop/master

Do you recommend a diff against your branch?

libqtile/manager.py/cmd_function, btw ;)

Ah, cool. Looks exactly like what I had :-). And yeah, I think my branch is the only one with 1.3.1 merged into it.

Right, I ran a diff last night with your master v freedesktop/master and I poured over it a lil' and it seems there are quite a few changes here and there.

I'd like to test that cmd_function a bit more and also, maybe look into creating a decorator to apply to functions?

Something like:

    @keycommand(Key([alt], "f"))
    def super_awesome_function(qtile):
         qtile.groupMap['group1'].windows
         # do awesome cool stuffs
         return 1

Thoughts on that? Lazy has a reference to Qtile therefore a reference to the commands. Could work with some minor modifications to manager.Key.

Finally, me and Cjbarnes had a pretty boss idea of having app specific key maps using the Qtile.keyMap dictionary and mutating it on python client_new and python focus_change hooks. Thoughts on that? Could even hook layout_change to modally change the keyMap because there are some commands that become rundundant in people's configs in certain layout modes.

Just a thought, the keyMap mechanism is very interesting!

Evidentally, I'm a github markdown noob,