I am beginning to wonder if the gtk-rs solution to the problem, whilst nice, and very "reactive", can actually be handled in a slightly different way in GtkD – since spawned threads have an implicit channel.

As you noted in a different discussion point,

https://github.com/gtkd-developers/GtkD/blob/master/demos/gtkD/DemoMultithread/DemoMultithread.d

shows how to use receiveTimeout in an idle callback on the GTK+3 event loop – this is analogous to putting a future on the event queue in gtk-rs. My spawned processes are external to the ApplicationWindow rather than handled by it, but that is just a parameter passing issue – though there may be some ordering problems. Also choosing the timeout value so as not to upset the UI may be tricky, and here lies the different between this solution and the gtk-rs one, the GtkD one requires polling, the gtk-rs one relies on events throughout (as far as I know).

I shall give this idea a go anyway. Isn't it great how reading all the threads is a good thing. :-)