GUI Toolkit Proposal

[Rob Thornton]

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

[Robert Johnstone]

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.

[Rob Thornton]

Thanks for your input! See my responses below:

On Saturday, 1 June 2013 11:11:13 UTC-7, Robert Johnstone wrote:

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.

This is where I hoped an effort like the wde[1] project would be a nice fit. It would serve to be a cross-platform tool to create a window in order to embed webkit in it. It shouldn't be too problematic to either fork one of the webkit projects or submit a patch which would use wde as a backend.

 

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.

 

While I agree that this might be better, long-term solution it would be, as you say, a LOT of work. The solution I propose is much more attainable with relatively less effort.

 

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.

I thought of Tk, FLTK and some other simpler, straight UI toolkits. My issue with these are that they aren't 'pretty' in the conventional sense. I think to appeal to a broader audience of developers, one's who want to create beautiful user interfaces, they would not be an entirely good choice. This is why I thought the html/css route would be better.

 

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

[1] https://github.com/skelterjohn/go.wde 

[Gerard]

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
• Binding C is quite easy. I think binding C++ has some nasty surprises and will bite you.
• Binding tcl/tk isn't the answer either.
• Cross platform with native look and feel, also Wayland support.
• It takes a lot of time defining your own GUI. No offense, but how usable is go-uik at the moment? GTK is mature and stable.
• You still can have all the goodies of Go in the wrapper.

Ok, it has some issues:

• Big executable file size (5M minimum) (who cares?)
• Wrapping isn't fast. Callbacks are slow. (who notices?)
• Not exactly native, but is still looks damn good
• ...

In the end, I think the advantages are just too good to ignore. GTK+ 3.X is here already. This is the way to go!

[André Moraes]

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".

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.

go-uik/go-wde will be the best solution in the long-term, but if you
need to do something right now, they aren't really a choice.

--
André Moraes
http://amoraes.info

[Erwin]

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.

[Tim Shannon]

That would be an intriguing project.  If you have an open repo, I'd like to follow it.

[Mandolyte]

The Ubuntu folks are focused on MIR and mostly Qt/QML... any thoughts on these?

[Rob Thornton]

Speaking personally, until such time MIR has broad adoption amongst most distributions I certainly wouldn't dedicate any time to it. Are the Ubuntu folks concentrating on Qt/QML? Last I saw, and I admit it's been a while, they've been focusing on Unity which is still, as far as I know, a GTK+ 3 based UI.

I agree with Andrea that go-uik is probably the best long term solution. Another, better long term solution is a unified Go front end which acts as an intermediary for other, native toolkits. Meaning, the go GUI interface would call Cocoa, WinAPI, GTK+, or whatever toolkit the user has installed depending on the platform but the common API would be identical across all platforms. The problem, of course, is that each toolkit behaves very differently and have different available functionality. This would be another difficult solution.

[Jeremy Wall]

On Wed, Jun 5, 2013 at 11:08 AM, Erwin <snes...@gmail.com> wrote:

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.

Ghost is actually pretty nice and is a pure C implementation last I looked so cgo bindings should be relatively painless. I don't think they've split it out into a standalone library though so that part might get a little rough.

 

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

[Kees Varekamp]

I would like to point out IUP (http://www.tecgraf.puc-rio.br/iup/) - it's a wonderful small windowing toolkit from Brazil that uses native windowing systems.

There is a Go binding for it too: https://github.com/jcowgar/go-iup . But it hasn't been updated in a looong time, and it's also not complete.



On Friday, June 7, 2013 6:01:44 AM UTC+12, gvds...@gmail.com wrote:

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.

And if you (or anybody) want a gui builder, just use glade (and look at builder example).

 

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.

[Stan Steel]

There are the beginning of GTK3 bindings here (not mine):

   https://github.com/norisatir/go-gtk3

and I was working on a ragel based translator just last week in
an effort to automatically derive "good" bindings from GTK3
header files.  I am not a fan of SWIG and I rather like mattn's
approach in his bindings.  I am not keen on keeping them up
to date manually, however.

I think, however, the more the merrier. 

[Gerard]

I forked the repo. It's https://github.com/grd/go-iup and works on Ubuntu 12.04. I didn't check it on Windows yet. Maybe this weekend (or not).

Also I added a 10 minute quick install guide which makes it a lot easier.

[Jan Mercl]

On Fri, Jun 21, 2013 at 9:08 AM, Gerard <gvds...@gmail.com> wrote:
> I forked the repo. It's https://github.com/grd/go-iup and works on Ubuntu
> 12.04. I didn't check it on Windows yet. Maybe this weekend (or not).
> Also I added a 10 minute quick install guide which makes it a lot easier.

This is an interesting project. Its repository doesn't have the issues
facility enabled, so I'm writing here a wish list:

- I suggest to rename the repository from 'go-iup' to, for example,
'iup'. The 'go' prefix is superficial, no name clash exists. Using
punctuation in the repository name is superficial and IMO makes never
any sense.

- I suggest to rename all sub directories in the repository having the
superficial 'iup' prefix to not have that prefix.

-j

[hoefnix]

Jan, sorry I mailed you privately. The issues facility should now be enabled.

About the issues: 

- I forked it and didn't think about the name. However iup (or go.iup) is ok with me. This also applies to the subdirectories.

- Windows turns out to be a problem (win7 64-bit) because mingw is complaining about that. (should be solvable)

[Gerard]

And I should also fix this "identity crisis".

[Jan Mercl]

On Fri, Jun 21, 2013 at 4:02 PM, hoefnix <hoef...@gmail.com> wrote:
> Jan, sorry I mailed you privately.

No problem.

> The issues facility should now be
> enabled.

Thanks!

> About the issues:
> - I forked it and didn't think about the name. However iup (or go.iup) is ok
> with me. This also applies to the subdirectories.

Please no punctuation. Ideal repository name == package name as seen
in the package statement ('iup' in your case).

Also, now I note that the package is "sunked" one level lower, in the
iup directory. That's not needed. Please "pull" the package one level
up, to the root of your repository.

I highly recommend to use the very simple schema. For example:

Let's have a package 'foo' having one file, named foo.go. In my case
its repository will be github.com/cznic/foo. The foo.go file should be
found, after 'go get github.com/cznic/foo' in
$GOPATH/src/github.com/cznic/foo.go.

That way it can be imported like 'import github.com/cznic/foo'.

In your case, to import iup, one has to write: 'import
github.com/grd/go-iup/iup'. That's one level off and it's IMO only
unnecessary stuttering.

Keep it simple ;-)

-j

[John Asmuth]

On Friday, June 21, 2013 10:06:10 AM UTC-4, Jan Mercl wrote:

Please no punctuation. Ideal repository name == package name as seen
in the package statement ('iup' in your case).

I respectfully disagree. Especially for something that is cross-platform, having the platform identified in the name is very useful.

+1 go.iup

[Gerard]

Sorry, the damage is already done ;)

I renamed it to github.com/grd/iup

[Jan Mercl]

On Fri, Jun 21, 2013 at 4:29 PM, John Asmuth <jas...@gmail.com> wrote:
> I respectfully disagree. Especially for something that is cross-platform,
> having the platform identified in the name is very useful.
>
> +1 go.iup

FWIW: The original C project is at
http://sourceforge.net/projects/iup/, not
http://sourceforge.net/projects/c.iup/ . Actually, I haven't yet seen
any c.foo C project. Also, I consider the Go repository, including
it's subrepos a standard to follow. No repository path basename has
punctuation there.

-j

[GreatOdinsRaven]

My 2 cents - I think "cross-platform" GUI toolkit will be a thing of the past, sadly. 

Windows, starting with Windows 8 and the App Store, is abandoning Win32/GDI and moving to XAML + WinRT, which are completely different and not backwards compatible. Apple with OS X is Cocoa all the way. What does that leave besides Linux?

Qt seems to be slowly going away. 2-3 years ago, I had at least 5 Qt apps on my Mac. Since then, Skype has gone native. VLC went native. I think the only Qt apps left are Steam and Spotify, and Spotify just released a browser version, so there will soon be one. I believe at this point I have exactly 3 non-Cocoa apps and those are various Java IDE's. And the way they *don't* fully integrate with my desktop experience, due to targeting the lowest common denominator, is a jarring, unpleasant experience - everything from fonts, to buttons, colors....

The OSes have drifted further and further apart, and will continue to do, offering different user experiences, different types of input, different flavors of "full-screen support", etc. 

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

[Dan Kortschak]

Package base names don't, sub-repo base names do.

[Jim Ellis]

On Friday, June 21, 2013 10:22:41 AM UTC-5, GreatOdinsRaven wrote:

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

 

First, IMHO HTML5/CSS3 would be approach, with a lot less reliance on js.

GUI - graphical user interface.

A GUI is basically a "middle man".

It is the way that the end user can interact with the program, by entering data, making selections, and viewing results.  The interface itself is just a container that does not do any real work of the program.

And it interacts the operating system, accepting the input, whether it be from touch, keyboard, mouse, or pen/stylus, and in taking the output from the program and displaying it on a screen.  

Windows, Mac, Linux, droid & iOs make it hard to have a "native" user interface that will work on each one.
And who knows what the next operating system will bring.

To me it seems that the biggest thing lacking in go is the "hooks" to provide for go to "talk" with a user interface.  From what I have seen, right now the only real "hooks" are with a browser. 

After giving this issue a bit of thought, I can "live" with using a browser as the GUI.

 

Browsers provide the interaction between the user and the operating system.

And when some of the newest "candidate" standards get adopted the browser will be even easier to use as that interface.

(grid layout and flex-box are 2 standards that would make using a browser much easier on layout of a page/screen).

As it is, browsers provide many input features, buttons, text boxes, etc.....

And as the standards are adopted, there will be more input verification built into the browsers.

Browsers make it very easy to show text and pictures.  

With the canvas and SVG, browsers provide a pretty good way to show custom graphics.

And right now (most importantly for me), browsers provide the "hook" to interact with a go program.

IMHO, Browsers are not perfect, and I believe there are better interactions between a native GUI and a program, as the native GUI has more "hooks" that provide more control, and make it easier to design the screens that the users will be interacting with.

 

But at this time, to me the browser provides the "best" UI to use with go.

One other feature that it provides is that you can make a program more "seamless" between the web version and a device version.  Many of the programs used and designed merge the "cloud" with the device, so this seamless approach just makes sense to me.

my 2¢,

Jim.

[Archos]

notanos has been built in JS:

https://github.com/Lerc/notanos
https://news.ycombinator.com/item?id=5932209

But taking that idea, it could be built built in other language and allowing the usage of JS or better Dart for the front-end so the applications could be easily used from web too.

[Niklas Voss]

My personal point of view if I understood you right is very similar to yours. I actually wanted to start a project earlier this year binding CEF1 via SWiG to use it

for a golang GUI library. This would allow interacting with the DOM and reacting to requests directly from golang.