Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

andlabs.lostsig.com

Post reply on HN
Print view View original

1–10 of 16 posts

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

#2

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

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

#3

Post by shaunxcode »

andlabs wrote: post #2

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 pl…

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 plans for the future

#5

Post by grey-area »

andlabs wrote: post #2

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 pl…

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 plans for the future

#6

Post by dimsuz »

shaunxcode wrote: post #3
andlabs wrote: post #2

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 pl…

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?

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

#7

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

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

#8

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

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

#9

Post by shoover »

sriku wrote: post #7

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 sens…

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 plans for the future

#10

Post by arethuza »

glutamate wrote: post #8

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

Post reply on HN