

My Golang UI package: lessons learned about threading and plans for the future - axk
http://andlabs.lostsig.com/blog/2014/06/27/61/my-ui-package-lessons-learned-about-threading-and-plans-for-the-future

======
andlabs
Note: since writing that article I have now started, and am now mostly
finished with, this rewrite, having only one last ink to work on... dialog
boxes. This was always a big disaster ecause every OS has a wildly different
model, and now I'm sitting on a Stack Overflow question related to Cocoa
thinking if I should just force all dialogs to be application modal but then
need a way to make them always on top on all platforms...

~~~
shaunxcode
I am curious to know if you spent any time studying the eXene
([http://alleystoughton.us/eXene/future.pdf](http://alleystoughton.us/eXene/future.pdf))
approach? I ask because it is the an ML CSP informed UI toolkit. If so how
would you contrast that with your current (new api) approach?

~~~
dimsuz
Interesting project. Looks like it's somewhat stalled, do you know anything
about its current state/plans?

------
andlabs
A bunch of people have commented on this blog post wearing me away from this
new design. To their credit, yes, things do get unwieldy fast... but now I'm
not sure where I want to take things as far as event handling is concerned.
Maybe I'm wrong about callbacks; I don't know...

The idea to make individual changes asynchronous by default looks like it
wouldn't be much of an issue :S

~~~
andlabs
I'm now willing to try callbacks because I have no idea anymore.

[http://andlabs.lostsig.com/blog/2014/06/27/61/my-ui-
package-...](http://andlabs.lostsig.com/blog/2014/06/27/61/my-ui-package-
lessons-learned-about-threading-and-plans-for-the-future#comment-18)

What do you all think of this design?

------
glutamate
Some time ago, Joe Armstrong wrote a thread-based binding to the X11 protocol
called ex11. Every widget would run in its own thread and listen for messages.
I keep on thinking about implementing something like that for the web.

ex11 is available on Github
([https://github.com/baryluk/ex11](https://github.com/baryluk/ex11)) and there
is a presentation
([http://www.erlang.org/workshop/2004/ex11.pdf](http://www.erlang.org/workshop/2004/ex11.pdf))

~~~
arethuza
For some reason that reminded me of NeWS, which I vaguely remember had co-
operative multitasking of threads within the display server itself.

Object oriented, multi-threaded PostScript FTW!

[http://en.wikipedia.org/wiki/NeWS](http://en.wikipedia.org/wiki/NeWS)

------
sriku
It almost seems like what you're looking for is a "React for Go". Channels may
be used for the underlying machinery, but the core abstraction is the
Observable (explicit model of values that change in time). For example, your
label's text value would be an observable and not an "object property" that
you set/get.

Disclaimer: I don't think I have a clear idea of what you're trying to do here
in the cross platform sense, except that I've also used channels to build Ui
components.

~~~
shoover
I think you mean Reactive Extensions since that uses observables. React(.js)
is about component rendering as functions of app state and tries to get away
from explicit observation. I've used Rx with some UI stuff but have not found
it to be a panacea for complex applications.

I would be very interested to see efforts to implement React.js ideas on the
desktop.

~~~
sriku
Yes I meant what "Reactive Extensions" does. Should've been clearer that it
was a reference to "functional reactive programming" and not a specific
library.

edit: "Async Javascript at Netflix" is a great talk on this -
[https://www.youtube.com/watch?v=XRYN2xt11Ek](https://www.youtube.com/watch?v=XRYN2xt11Ek)

------
colin_mccabe
I think it's really cool that you're writing this library for Go. It will be
nice to have some native GUI library.

When it's further along, you should consider giving people some way to exploit
platform-specific GUI features. Something that gives people that ability to be
portable if they want, but also optionally use platform-specific GUI features
would be the Go-like way to do things (as opposed to the Java-like way of
bringing everyone down to the lowest common denominator.)

Multithreaded GUI toolkits do seem to be hard. My favorite essay on this is:
[https://weblogs.java.net/blog/2004/10/19/multithreaded-
toolk...](https://weblogs.java.net/blog/2004/10/19/multithreaded-toolkits-
failed-dream)

It sounds like you may have encountered some of the same issues. The new
handler design seems sensible.

------
ChikkaChiChi
Can't wait to see your rewrite go live!

