"I've been working on a proposal for a GUI toolkit for Go. I'm curious to know what others think. What's good and what's not? Is it reasonable? Would people be interested to work on it? How does the community, as a whole, feel about it?"
http://noeffclue.blogspot.ca/2013/06/proposal-for-gui-toolkit-for-go.html
This is something that I would like to see as well. I'm certain I'm not alone. I have a few comments to add to your summary.
1) The approach started by GoWebKit does not necssarily rely on GTK. For example, you could use GTK with the GTK webkit on linux, and use a different port of WebKit on windows with the windows native API. The idea would be to provide a routine with a fixed signature to start a top-level window that contains a WebKit widget. There is also the Chromium Embedded Framework. The majore problem I've had with this approach is that, other than GTK webkit, the others are poorly docuented, and I've not had the time to get anything running.
2) One approach that you omitted is SWT, which is a Java toolkit that wraps native widgets. This may be a good approach for Go as well, but it would still be a lot of work. Eclipse has a reputation for being quite slow, but it is not clear to me that the same approach in Go would necessarily be slow as well.
3) Wrap a smaller GUI library that is already cross-platform. Here we are looking at wxWidgets or Tk. Wrapping these libraries in a manner that makes for idiomatic Go would still be quite a bit of work, but would probably be a lot less than wrapping a beast such as Gtk, which doesn't even provide native widgets outside of Linux.
On Saturday, 1 June 2013 13:07:24 UTC-4, Rob Thornton wrote:I've posted this in the Go G+ group as well. To quote what I said there:"I've been working on a proposal for a GUI toolkit for Go. I'm curious to know what others think. What's good and what's not? Is it reasonable? Would people be interested to work on it? How does the community, as a whole, feel about it?"
http://noeffclue.blogspot.ca/2013/06/proposal-for-gui-toolkit-for-go.html
I've been pondering on porting the blender GUI to Go. It doesn't have the native OS looks, but I quite like it. If depends only on OpenGL (for rendering) and will look the same on all platforms. I haven't had a closer look at the amount of code, nor have I the time right now to even attempt a port, but it could be a practical way to make some progress on the Go GUI front.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Wednesday, June 5, 2013 5:43:34 PM UTC+2, André Moraes wrote:On Wed, Jun 5, 2013 at 9:54 AM, Gerard <gvds...@gmail.com> wrote:
> I have seen lots of GUI initiatives on golang-nuts. Of course there has got
> be a cross platform GUI someday.
> But, I think that wrapping GTK+ >= 3.8 is the way to go. Why?
>
> Mattn and others have done a lot of work already. See
> https://github.com/mattn/go-gtk
go-gtk uses gtk 2.x
gtk 3.x is different from gtk 2.x (they use something called object inspection)
afaik, gtk 3.x don't have windows bundles or is "supported".
Sorry, I messed up. It's GTK2 dll's on Windows. You are correct. But that undermines my posting. mattn's package is ready as it is right now.
Recently I just gave up trying to write GUI in go (except for playing
around with sdl+opengl or wde/uik). What I am doing is using
node-webkit or appjs to create the UI and websockets to make RPC
between Go and javascript.
Yes that's also possible.
Please no punctuation. Ideal repository name == package name as seen
in the package statement ('iup' in your case).
My 2 cents - I think "cross-platform" GUI toolkit will be a thing of the past, sadly.
I'm seriously not trying to be a downer, I just don't know what a "cross-platform" app would even mean in another 3-4 years unless it's HTML5/JS...