Are channels and CSP failing as the favored design approach? I keep seeing frameworks that just seem to use Go as if it were C with closures.
Gotk3: GTK3 the Go way
41–50 of 58 posts
Re: Gotk3: GTK3 the Go way
#42Earlier quoted context omitted.
In short, we weren't aware of the project. I just gave it a try now, but the code will not compile on my dev box (OpenBSD, go tip). Even after making some minor fixes (I fixed an #include directive, removed a call to a deprecated function, etc.) there appear to be some serious issues (one error I got mentioned the size of an array being negative). It appears this code has not been updated in a year, and we wished to…
Just to be clear, this isn't my project, but it has been working fine for me for awhile now, but I am probably not exercising the same pathways as you. Anyway, I have written additional bindings for the Gtk Docking Library and the Syntax Highlighter against this project. Everything compiles, runs, and works well. It is a little frustrating as it is one of the first projects that comes up when searching for "go" and "…
So this was just me not being aware of it, but others of us at Conformal were, and due to the above issues we decided to do our own.
Re: Gotk3: GTK3 the Go way
#43I was kinda meh on Go (reminded me of my days in the Ada code), but making native GTK Apps seem really interesting to me. Will have to check this out.
From poking around, still a pipe dream for the moment.
Re: Gotk3: GTK3 the Go way
#44Re: Gotk3: GTK3 the Go way
#45Earlier quoted context omitted.
Preferring RAII over garbage collection is the decision that Rust made. Probably the reason that more languages don't use RAII for memory management is safety. C++, even with RAII, is not safe—you can violate memory safety with certain uses of references and iterators. Rust has to go to great lengths (lifetimes and the borrow check—things that have only been in the research landscape) to make this safe.
I'm actually a huge fan of Rust's memory model and wished Go had something similar, since it's faster to use smart pointers, and less calls to the garbage collector are required. I also love how rust uses three different kinds of pointers depending on how the memory is managed, and although it adds some complexity, it gives more semantic value to the data you are working with. Unfortunately for me, the rust compiler…
Re: Gotk3: GTK3 the Go way
#46Re: Gotk3: GTK3 the Go way
#47Glad 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…
Re: Gotk3: GTK3 the Go way
#48Earlier 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.
https://qt-project.org/doc/qt-5.0/qtcore/qmutexlocker.html#d...
Re: Gotk3: GTK3 the Go way
#49Does 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.
1. Standard C++ ui designed in a form designer and connected to C++ classes.
2. QML + javascript.
3. OpenGL with the ability to use widgets on the OpenGL viewport.
Re: Gotk3: GTK3 the Go way
#50Does 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.
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.