Concurrency in UI Toolkits | Hacker News Reader

Concurrency in UI Toolkits

guigarage.com

21 pointsdesdiv6 comments

One solution is to use generators in Python. The new Asyncio framework makes it easier to think about concurrency in GUI applications, and it can be used to cooperate with several GUI frameworks' event loops, like QT and Kivy, as well as websockets and other contexts.

It's not immediately obvious how to "yield from start_button()", but the solution is to have a FIFO command queue like in this article. The UI thread pushes commands to this queue and then the coroutine can act on the command.

This also simplifies changing the exact meaning of buttons/keys like "back" depending on the context, and handling multi-step network tasks, like using external APIs, ssh commands to a server, file downloads and the like. Using a command queue in Asyncio makes UI actions and IO events interchangeable.

Part 2 here: http://www.guigarage.com/2015/02/concurrency-ui-toolkits-par...

> Today every UI toolkit that is not running in a browser needs a UI Thread

This highlights why the idea of running a UI in the browser is actually seriously broken.

Code running in the browser also has a UI thread that it needs to run on. Just that until recently the UI thread was the only thread you had access to.

Actually, it's the other way around: the single thread in a browser is an UI thread, and what's seriously broken is using it for anything else!

If you ever want to do non-UI work, you should use Web Workers, which were invented specifically because doing non-UI complex tasks in the UI thread got really common when HTML unexpectedly became an application platform.

WPF has not only a UI thread, but a closed-off rendering thread responsible for translating scene graph modifications into screen pixels. It was never clear to me if browsers did the same thing (dom being changed in the single UI thread, dom changes being processed in an off limits rendering thread).

Reply on news.ycombinator.com