Asyncio-based event loop

The move to a fully pip-installable Qtile! (once cairocffi merges XCB support...)

One thing is I've decided to support the asyncio module where available (in the standard library [asyncio module](https://docs.python.org/3/library/asyncio.html) for >=3.4 and [Tulip](https://code.google.com/p/tulip/) for 3.3), falling back on [trollius](http://trollius.readthedocs.org/) for 2 and <=3.3. We obviously couldn't do `yield from ...`, which is only valid syntax >=3.3, but we also can't use the trollius style `yield From(...)`. We could make everyone install trollius, which would let us do this, but I'm not sure it lets us do much more. We might consider this if we find a case where it's too hard to support both.

This will probably need people to just play around to try to work out any kinks. In particular, I stopped `conn.flush()` from running at every step of the event loop, since there isn't really a comparable function to `context.iteration()`, and moved it to `._loop()`. This is run on startup, after `._xpoll()`, after `call()`'s in command.py, and after `draw`'s in drawer.py. We will probably have to play around with this to get it called when we need it.

I've implemented a new IPC protocol based on [asyncio transports and protocols](https://docs.python.org/3/library/asyncio-protocol.html). This seemed to occasionally hang on Travis waiting for the server, particularly on 3.3 (maybe it's something with Tulip?), so I set huge timeouts (30 s) on the client waiting for reply. I can't pin down the problems here, since they always work fine for me, hopefully debugging can work this out. Also, there is probably more that can be done here to use more asyncio stuff.

I also started to change the docs to reflect the cffi changes. There are still a lot of TODO's related to getting stuff into distros, but at least the install from source page should be good for pointing people to.

TODO:

- [ ] Fix `cmd_spawn`
On Fri, Aug 15, 2014 at 11:09:15AM -0700, Sean Vig wrote:
> > @@ -1175,12 +1185,10 @@ def cmd_spawn(self, cmd):
> >  
> >                  spawn("firefox")
> >          """
> > -        pid, _, _, _ = gobject.spawn_async(
> > -            [os.environ['SHELL'], '-c', cmd],
> > -            flags=(gobject.SPAWN_STDOUT_TO_DEV_NULL |
> > -                   gobject.SPAWN_STDERR_TO_DEV_NULL)
> > -        )
> > -        return str(pid)
> > +        import shlex
> > +        from subprocess import Popen
> > +        p = Popen(shlex.split(cmd))
> > +        return p.pid
> 
> I've added a call in `_loop` that `.poll()`s the processes that have been spawned, so they won't become zombies, and that seems to work. Ideally, there is a better solution that doesn't involve having to manually poll everything...
> 
> This also comes with the side-effect of killing all spawned processes when qtile dies. I don't know if this happened before, but it is interesting. Re-starting qtile may also have some interesting effects on spawned processes.

Oh, that is a good point. That + less code makes me think daemonizing
like gobject does is probably a good idea. Presumably they do
something like this:

```
import os
import time
import sys

# i am the main qtile process

pid1 = os.fork()

if pid1 == 0:
    # i'm the first child, re-fork so we daemonize
    pid2 = os.fork()
    if pid2 == 0:
        # here we should exec()
        while True:
            time.sleep(1)
    else:
        sys.exit()
else:
    os.waitpid(pid1, 0)

    # continue qtile stuff here
    while True:
        time.sleep(1)
```


> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/tych0/qtile/pull/17/files#r16306441