add traitlet to ServePostProcessor that configures the browser used

[mpacer]

This closes #614.

I took some of the design of how the notebook implemented this and tried to abstract away only those parts that we needed.

In particular, I didn't run the browser.open command using threading.thread, since multi-threading didn't seem necessary, but that might be wrong. Could use others' insights.

[takluyver]

I think that wrapping it in a thread is needed in some situations, because browser.open() might try to wait for the process it launches to exit before returning. Looking at the code of the webbrowser module, I think this would affect you if you set the BROWSER env variable and didn't already have the browser running when Python tried to launch it.

[minrk]

I believe it's only on Linux where open can block, and there only when the browser application is not already running, as Thomas mentioned.

[takluyver]

I think it can happen on any system if you have the BROWSER environment variable set; that's registered as a GenericBrowser regardless of your platform. It's a corner case, but I suspect enough people will run into it to be worth considering - especially because the failure mode will be confusing: the browser will start and the server won't be running.

[takluyver]

This won't actually do it in a thread - you're calling browser.open() in the main thread, and passing its return value as the target= parameter.

You can either use a lambda, like we do in notebook, or pass args and kwargs separately, like this:

Thread(target=browser.open, args=(url,), kwargs={'new': 2})

Both ways are a bit ugly, unfortunately.