My Golang UI package: lessons learned about threading and plans for the future | Hacker News Reader

My Golang UI package: lessons learned about threading and plans for the future

andlabs.lostsig.com

81 pointsaxk15 comments

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...

I am curious to know if you spent any time studying the eXene (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?

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

Have you looked at setLevel on NSWindow?

[dialog setLevel:NSStatusWindowLevel];

It's probably not a viable solution long-term because users will expect more Mac OS X-like behaviour and non-modal dialogs, but it would help you do what you want I think.

Actually OS X is the only system that guarantees application-modal dialog boxes stay always on top; it's the other platforms that I would need to worry about.

ah ok, sorry I misunderstood.

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

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-...

What do you all think of this design?

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) and there is a presentation (http://www.erlang.org/workshop/2004/ex11.pdf)

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

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.

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.

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

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...

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

Can't wait to see your rewrite go live!

Reply on news.ycombinator.com