Gotk3: GTK3 the Go way • Hacker News Board

Re: Gotk3: GTK3 the Go way

#51

Post by matthiasv » Wed, Jul 17, 2013, 6:29 AM UTC

coldtea wrote: post #50

pionar wrote: post #46

Does anyone else think we need a new open-source widget toolkit? Qt, GTK, and what else is there? Those guys are old. I've done both, and WPF, and WPF is just so much better. I wish there was an open-source toolkit that didn't just suck.

Yes, most are old and tiered. But another problem is, there is not a company/organization or even language community to take on such a big endeavour. I'd like to see a C based toolkit, that's made specifically for wrapping it up for other languages (in C++, Ruby, Python, Go etc) and has niceties to help with this.

> I'd like to see a C based toolkit, that's made specifically for wrapping it up for other languages (in C++, Ruby, Python, Go etc) and has niceties to help with this.

This is exactly, why GTK+ and essentially the whole GNOME stack is now introspected with GObjectIntrospection. So, there you have it.

Re: Gotk3: GTK3 the Go way

#52

Post by [deleted] » Wed, Jul 17, 2013, 6:41 AM UTC

MetaCosm wrote: post #40

tptacek wrote: post #17

Earlier quoted context omitted.

This approach starts getting brittle when you get into objects that aren't procedure-scoped; for instance, a global session table in a web application, or a request token tracker in an RPC system. These are also the kinds of object lifecycles that tend to be behind leaks and corruption in programs that don't use RAII. People use shared pointers to mitigate that problem, but shared pointers are (a) a reference countin…

I think the biggest fans of RAII are those who use it more academically -- in real life it is brittle and scopes are tricky. It is also just an idiom as compared to a compiler feature. And, IMHO, RAII tends to play poorly with others.

[deleted]

Re: Gotk3: GTK3 the Go way

#53

Post by asb » Wed, Jul 17, 2013, 6:48 AM UTC

georgemcbay wrote: post #27

Glad to see some more work being done on UI frameworks in Go, though I doubt this will end the splintered nature of all the different (mostly half-baked, honestly) options. I've personally been using a Qt5.1/QML based solution with a Go/CGO based QML plugin that acts as a bridge between QML and backend Go code. It doesn't try to export much of Qt to Go, it basically expects you to write the UI logic in QML/QtQuick an…

I'd also love to see some source to get an idea of how this works and what the binding code you end up writing looks like.

Re: Gotk3: GTK3 the Go way

#54

Post by owaislone » Wed, Jul 17, 2013, 8:56 AM UTC

georgemcbay wrote: post #27

Glad to see some more work being done on UI frameworks in Go, though I doubt this will end the splintered nature of all the different (mostly half-baked, honestly) options. I've personally been using a Qt5.1/QML based solution with a Go/CGO based QML plugin that acts as a bridge between QML and backend Go code. It doesn't try to export much of Qt to Go, it basically expects you to write the UI logic in QML/QtQuick an…

QT+Go can prove to be an awesome combination. Really hope you release a preview soon.

Re: Gotk3: GTK3 the Go way

#55

Post by gophering » Wed, Jul 17, 2013, 10:14 AM UTC

Just tested on win7 and everything works great! Really nice work.

Re: Gotk3: GTK3 the Go way

#56

Post by pjmlp » Wed, Jul 17, 2013, 11:42 AM UTC

fs111 wrote: post #34

mortdeus wrote: post #28

Earlier quoted context omitted.

gnome tool kit. Note that gnome is pronounced gi'nome just like gnu is pronounced gi'new.

gimp toolkit. gtk is older than gnome and was made by the gimp devs.

I still remember Gimp's first release. Uhm, I guess I'm getting really old.

Re: Gotk3: GTK3 the Go way

#57

Post by joeshaw » Wed, Jul 17, 2013, 3:06 PM UTC

No mention of goroutines or concurrency in the post. Is it addressed by the project at all? I can't imagine that the GTK main loop will deal well with being cooperatively scheduled -- the UI would block any time another goroutine ran on the same OS thread.

Ideally the GTK main loop would run in its own OS thread, and there would need to be a way to ensure that no GTK calls happen in other goroutines. Other (threaded) environments tend to handle this by deferring via a one-off "idle" function that is scheduled and run by the GTK main loop for things like that.

Re: Gotk3: GTK3 the Go way

#58

Post by jrick » Wed, Jul 17, 2013, 5:21 PM UTC

joeshaw wrote: post #57

No mention of goroutines or concurrency in the post. Is it addressed by the project at all? I can't imagine that the GTK main loop will deal well with being cooperatively scheduled -- the UI would block any time another goroutine ran on the same OS thread. Ideally the GTK main loop would run in its own OS thread, and there would need to be a way to ensure that no GTK calls happen in other goroutines. Other (threaded)…

We do try to deal with concurrency and goroutines as much as we can. I'd recommend taking a look at the (rather simple) goroutine example as part of the gtk package. Unfortunately though, as you said, GTK is not thread safe (calling GTK from multiple threads was deprecated as of the last release I believe) and calls must be made using glib.IdleAdd() to run the functions in GTK's main loop context.