7 ms·

Out of interest, can you point me to any GUI bindings or native Go GUI toolkits etc.? I would like to take a look, as I am normally writing native C++ GUI deskt

Out of interest, can you point me to any GUI bindings or native Go GUI toolkits etc.? I would like to take a look, as I am normally writing native C++ GUI desktop apps. EDIT: Thanks for all the info everyone. I hope my responses don't appear argumentative - I am genuinely curious.

0xmohit 10y ago
I haven't tried it thus far, but you can see a list at the Projects wiki [0]. [0] https://github.com/golang/go/wiki/Projects#guis-and-widget-toolkits https://github.com/golang/go/wiki/Projects#guis-and-widget-t...
Klathmon 10y ago
I'm not sure if this would work for you, but using something like Electron and having your go program output HTML/JS/CSS as your UI works really well with go (or have your go program output JSON or something to communicate with the front end) If you throw something like react on there, you'll have a pretty simple functional UI, but if you don't want that there's nothing wrong with HTML/CSS and as little JS as you can get away with.
- 72deluxe 10y ago
  That sounds an interesting concept and useful for creating instantly-usable web apps but in effect isn't your Go app being relegated to a HTTP server? eg. how would I do callbacks without doing them as some request back to the Go "server" app? How would you create custom controls in this method? eg. if I wanted to do my own pie chart control/widget with popups etc. It sounds like a long way around in comparison to what you can do in C/C++, ie native calls depending on the platform, or use an abstraction toolkit like wxWidgets. (Oddly C++ has done well without any native GUI toolkit of course, but at least there was native C ones to use).
  - Klathmon 10y ago
    Ideally you would put as much of the "business logic" in the go code as possible, and have it "render" to something like JSON which the front end just reads in and displays. Interactions with the front-end just send a new request to the go code to handle and respond with what is needed. It is a lot more work for small applications compared to something like wxWidgets, but for larger applications the decoupling of the front end from the "back end" can help in a bunch of ways. It lets you develop them somewhat separately, it gives you a uniform look-and-feel across platforms (could be a pro or a con depending on how you feel about it), and allows you to do something like replace the web-front-end with a native system later if you want (and you could write the front-end in the platform's native GUI widget library for best performance and integration while keeping the backend code identical). So your go code is basically an HTTP server at that point, but it frees you up to let go do what it does best without worrying about how you will display it, and it lets javascript/html/css do what it does best (display stuff). I've had great success doing this once before, and if you have some experience with React, it works out really "beautifully" as the front-end can be completely stateless. So what was pushed to it from go is what is displayed. Easy to test, easy to develop, and easy to replace if needed.
  - pjmlp 10y ago
    > Oddly C++ has done well without any native GUI toolkit of course, Well from the OS vendors themselves we had MFC/WTL/Windows Forms/WTL on Windows, BeOS GUI, Symbian UI, CSet++ on OS/2, PowerPlant on Mac. Additionally there was Turbo Vision on MS-DOS, OWL, VCL for Windows, Motif++ on UNIX.
dilap 10y ago
I love Go and think it could be good in this area, but so far as I know no one is using it for any serious GUI work (yet?).
- 72deluxe 10y ago
  What is it being used for? HTTP servers? 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere?
  - vram22 10y ago
    >What is it being used for? HTTP servers? Yes, that is one big area - networked servers - a superset of HTTP servers. The Google site that serves the Chrome browser is supposed to be a Go app, and I've read Google uses Go a lot internally. (I'm sure Rob Pike and his team must be using it, after developing it for that very purpose.) Reading up on the goals of Go will give some insight into that. Part of the reason was that they wanted it to write big systems at Google, including networked ones, and wanted a better experience than they had with C++ (build times [1] and also other issues). Rob Pike has written some about it, others may have too). [1] This video that I blogged about: Video: C++, Rust, D and Go: Panel at LangNext '14: http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-panel-at-langnext.html http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-pane... has many interesting language-related discussions; one of them is the discussion about the build times of C++ vs. those of more modern language. There are concrete reasons why C++ build times are relatively so large - the use of include files is part of the reason - those are discussed some in the video, between the panelists, including some of the language (co-)inventors, such as C++'s Bjarne Stroustrup, Go's Rob Pike and D's Walter Bright. There is a nice moment or two near the end where Stroustrup responds about C++ build times - okay, won't spoil it for you and others - go see it :) Command-line tools is another area where Go is used a lot. Getting the convenience of deploying a simple single binary (maybe at the most a config file or two with it) even by just copying to the deploy target - unlike what you have to do with interpreted languages like Python and Ruby (unless you use something like PyInstaller or py2exe for Python, but that is not officially supported and may or not work for all Python apps [2]). This gives us back some of the convenience of older compiled languages like C where this was the normal way of deploying - but with some benefits over languages such as C (see Go vs. C topics), plus goroutines, channels, etc., I guess. Though I have not come across any examples of what things command line apps using goroutines and channels could be used for - it would be interesting to hear/read about some. I mean apart from a few somewhat obvious ones such as a web client to download multiple URLs in different goroutines, concurrently. [2] I've tried out PyInstaller on a few Python apps, including command-line apps, and a simple wxPython app or two - it did work okay for those, in the limited testing I did. Edit: fixed typos, added a few points.
gribbly 10y ago
I'm certain there are more, but here are a few platform native https://github.com/andlabs/ui https://github.com/andlabs/ui gtk http://mattn.github.io/go-gtk/ http://mattn.github.io/go-gtk/ qt https://github.com/therecipe/qt https://github.com/therecipe/qt qml https://github.com/go-qml/qml https://github.com/go-qml/qml shiny (still being developed, Go native) https://github.com/golang/exp/tree/master/shiny https://github.com/golang/exp/tree/master/shiny
vram22 10y ago
Here is one - WALK: https://github.com/lxn/walk https://github.com/lxn/walk A friend had used it in a commercial project, and IIRC he said it worked okay. Not tried it myself yet. I think it wraps the Win32 GUI SDK but also has a declarative mode [1] (at least for GUI widget layout) on top, or something like that - only looked at some sample code briefly. [1] meaning you can declare your GUI layout declaratively, but in Go code - it does not need XML or some other language or markup format like some declarative approaches do - IIRC. I actually wish the Go team had built support for some / many of the major GUI toolkits on major OS's (at least) from near the start of Go's development. I realize that there could have been, or still could be, some issues with that, due to differences between Go and (C and C++) [2] models (object file format, calling conventions, stack and heap layout, etc. - basically compiler and compiler-output-related stuff), and hence it may not be easy to create bindings from the former to the latter. Not familiar with this area. [2] since many of the major GUI toolkits are natively written in C or C++, so a Go wrapper would need to bind to them. Not complaining though, I know what they (the Go team and community) have already done is a huge achievement anyway.

0xmohit 10y ago

I haven't tried it thus far, but you can see a list at the Projects wiki [0]. [0] https://github.com/golang/go/wiki/Projects#guis-and-widget-toolkits https://github.com/golang/go/wiki/Projects#guis-and-widget-t...

Klathmon 10y ago

I'm not sure if this would work for you, but using something like Electron and having your go program output HTML/JS/CSS as your UI works really well with go (or have your go program output JSON or something to communicate with the front end) If you throw something like react on there, you'll have a pretty simple functional UI, but if you don't want that there's nothing wrong with HTML/CSS and as little JS as you can get away with.

72deluxe 10y ago
That sounds an interesting concept and useful for creating instantly-usable web apps but in effect isn't your Go app being relegated to a HTTP server? eg. how would I do callbacks without doing them as some request back to the Go "server" app? How would you create custom controls in this method? eg. if I wanted to do my own pie chart control/widget with popups etc. It sounds like a long way around in comparison to what you can do in C/C++, ie native calls depending on the platform, or use an abstraction toolkit like wxWidgets. (Oddly C++ has done well without any native GUI toolkit of course, but at least there was native C ones to use).
- Klathmon 10y ago
  Ideally you would put as much of the "business logic" in the go code as possible, and have it "render" to something like JSON which the front end just reads in and displays. Interactions with the front-end just send a new request to the go code to handle and respond with what is needed. It is a lot more work for small applications compared to something like wxWidgets, but for larger applications the decoupling of the front end from the "back end" can help in a bunch of ways. It lets you develop them somewhat separately, it gives you a uniform look-and-feel across platforms (could be a pro or a con depending on how you feel about it), and allows you to do something like replace the web-front-end with a native system later if you want (and you could write the front-end in the platform's native GUI widget library for best performance and integration while keeping the backend code identical). So your go code is basically an HTTP server at that point, but it frees you up to let go do what it does best without worrying about how you will display it, and it lets javascript/html/css do what it does best (display stuff). I've had great success doing this once before, and if you have some experience with React, it works out really "beautifully" as the front-end can be completely stateless. So what was pushed to it from go is what is displayed. Easy to test, easy to develop, and easy to replace if needed.
- pjmlp 10y ago
  > Oddly C++ has done well without any native GUI toolkit of course, Well from the OS vendors themselves we had MFC/WTL/Windows Forms/WTL on Windows, BeOS GUI, Symbian UI, CSet++ on OS/2, PowerPlant on Mac. Additionally there was Turbo Vision on MS-DOS, OWL, VCL for Windows, Motif++ on UNIX.

dilap 10y ago

I love Go and think it could be good in this area, but so far as I know no one is using it for any serious GUI work (yet?).

72deluxe 10y ago
What is it being used for? HTTP servers? 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere?
- vram22 10y ago
  >What is it being used for? HTTP servers? Yes, that is one big area - networked servers - a superset of HTTP servers. The Google site that serves the Chrome browser is supposed to be a Go app, and I've read Google uses Go a lot internally. (I'm sure Rob Pike and his team must be using it, after developing it for that very purpose.) Reading up on the goals of Go will give some insight into that. Part of the reason was that they wanted it to write big systems at Google, including networked ones, and wanted a better experience than they had with C++ (build times [1] and also other issues). Rob Pike has written some about it, others may have too). [1] This video that I blogged about: Video: C++, Rust, D and Go: Panel at LangNext '14: http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-panel-at-langnext.html http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-pane... has many interesting language-related discussions; one of them is the discussion about the build times of C++ vs. those of more modern language. There are concrete reasons why C++ build times are relatively so large - the use of include files is part of the reason - those are discussed some in the video, between the panelists, including some of the language (co-)inventors, such as C++'s Bjarne Stroustrup, Go's Rob Pike and D's Walter Bright. There is a nice moment or two near the end where Stroustrup responds about C++ build times - okay, won't spoil it for you and others - go see it :) Command-line tools is another area where Go is used a lot. Getting the convenience of deploying a simple single binary (maybe at the most a config file or two with it) even by just copying to the deploy target - unlike what you have to do with interpreted languages like Python and Ruby (unless you use something like PyInstaller or py2exe for Python, but that is not officially supported and may or not work for all Python apps [2]). This gives us back some of the convenience of older compiled languages like C where this was the normal way of deploying - but with some benefits over languages such as C (see Go vs. C topics), plus goroutines, channels, etc., I guess. Though I have not come across any examples of what things command line apps using goroutines and channels could be used for - it would be interesting to hear/read about some. I mean apart from a few somewhat obvious ones such as a web client to download multiple URLs in different goroutines, concurrently. [2] I've tried out PyInstaller on a few Python apps, including command-line apps, and a simple wxPython app or two - it did work okay for those, in the limited testing I did. Edit: fixed typos, added a few points.

gribbly 10y ago

I'm certain there are more, but here are a few platform native https://github.com/andlabs/ui https://github.com/andlabs/ui gtk http://mattn.github.io/go-gtk/ http://mattn.github.io/go-gtk/ qt https://github.com/therecipe/qt https://github.com/therecipe/qt qml https://github.com/go-qml/qml https://github.com/go-qml/qml shiny (still being developed, Go native) https://github.com/golang/exp/tree/master/shiny https://github.com/golang/exp/tree/master/shiny

vram22 10y ago

Here is one - WALK: https://github.com/lxn/walk https://github.com/lxn/walk A friend had used it in a commercial project, and IIRC he said it worked okay. Not tried it myself yet. I think it wraps the Win32 GUI SDK but also has a declarative mode [1] (at least for GUI widget layout) on top, or something like that - only looked at some sample code briefly. [1] meaning you can declare your GUI layout declaratively, but in Go code - it does not need XML or some other language or markup format like some declarative approaches do - IIRC. I actually wish the Go team had built support for some / many of the major GUI toolkits on major OS's (at least) from near the start of Go's development. I realize that there could have been, or still could be, some issues with that, due to differences between Go and (C and C++) [2] models (object file format, calling conventions, stack and heap layout, etc. - basically compiler and compiler-output-related stuff), and hence it may not be easy to create bindings from the former to the latter. Not familiar with this area. [2] since many of the major GUI toolkits are natively written in C or C++, so a Go wrapper would need to bind to them. Not complaining though, I know what they (the Go team and community) have already done is a huge achievement anyway.