5 ms·

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

81 points by axk 12y ago

andlabs 12y ago
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 12y ago
  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 12y ago
    Interesting project. Looks like it's somewhat stalled, do you know anything about its current state/plans?
- grey-area 12y ago
  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.
  - andlabs 12y ago
    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.
    - grey-area 12y ago
      ah ok, sorry I misunderstood.
ChikkaChiChi 12y ago
Can't wait to see your rewrite go live!
sriku 12y ago
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 12y ago
  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 12y ago
    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
glutamate 12y ago
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 12y ago
  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
andlabs 12y ago
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 12y ago
  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-lessons-learned-about-threading-and-plans-for-the-future#comment-18 http://andlabs.lostsig.com/blog/2014/06/27/61/my-ui-package-... What do you all think of this design?
colin_mccabe 12y ago
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-toolkits-failed-dream 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.

81 points by axk 12y ago

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 12y ago
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 12y ago
  Interesting project. Looks like it's somewhat stalled, do you know anything about its current state/plans?
grey-area 12y ago
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.
- andlabs 12y ago
  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.
  - grey-area 12y ago
    ah ok, sorry I misunderstood.

ChikkaChiChi 12y ago

Can't wait to see your rewrite go live!

sriku 12y ago

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 12y ago
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 12y ago
  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

glutamate 12y ago

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 12y ago
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

andlabs 12y ago

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 12y ago
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-lessons-learned-about-threading-and-plans-for-the-future#comment-18 http://andlabs.lostsig.com/blog/2014/06/27/61/my-ui-package-... What do you all think of this design?

colin_mccabe 12y ago

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-toolkits-failed-dream 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.