Re:My Golang UI package: lessons learned about threading and...
by andlabs on Monday June 30, 2014 @12:41AM
(#7963726)
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...
Re:My Golang UI package: lessons learned about threading and...
by shaunxcode on Monday June 30, 2014 @12:54AM
(#7963748)
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?
Re:My Golang UI package: lessons learned about threading and...
by grey-area on Monday June 30, 2014 @04:10AM
(#7964162)
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.
Re:My Golang UI package: lessons learned about threading and...
by andlabs on Monday June 30, 2014 @11:57AM
(#7965708)
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.
Re:My Golang UI package: lessons learned about threading and...
by andlabs on Monday June 30, 2014 @11:58AM
(#7965717)
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
Re:My Golang UI package: lessons learned about threading and...
by glutamate on Monday June 30, 2014 @06:28AM
(#7964401)
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.
Re:My Golang UI package: lessons learned about threading and...
by sriku on Monday June 30, 2014 @04:53AM
(#7964236)
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.
Re:My Golang UI package: lessons learned about threading and...
by shoover on Monday June 30, 2014 @10:19AM
(#7965143)
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.
Re:My Golang UI package: lessons learned about threading and...
by sriku on Monday June 30, 2014 @08:53PM
(#7968636)
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.
Re:My Golang UI package: lessons learned about threading and...
by colin_mccabe on Monday June 30, 2014 @11:27PM
(#7969044)
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.)
[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.
The idea to make individual changes asynchronous by default looks like it wouldn't be much of an issue :S
http://andlabs.lostsig.com/blog/2014/06/27/61/my-ui-package-...
What do you all think of this design?
ex11 is available on Github (https://github.com/baryluk/ex11) and there is a presentation (http://www.erlang.org/workshop/2004/ex11.pdf)
Object oriented, multi-threaded PostScript FTW!
http://en.wikipedia.org/wiki/NeWS
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 would be very interested to see efforts to implement React.js ideas on the desktop.
edit: "Async Javascript at Netflix" is a great talk on this - https://www.youtube.com/watch?v=XRYN2xt11Ek
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.