I decided to take an existing command line program that I've written and put a graphical interface on it using different GUI frameworks/tool kits that are available. The program's purpose is very simple. It checks for the latest stable version of Go for your system and if there is a newer version then it downloads it. Once the file is downloaded, it verifies the checksum to make sure that it correctly downloaded a good file. The UI will simply show the information (where to save, the version to download, the checksum) and a button to start downloading. During download, a progress bar indicates what is happening.
The code can be found at https://github.com/lazyhacker/getgo with the GUI files in the internal/gui package. gtk.go and fyne.go are for GTK and Fyne respectfully.
Go is perfectly capable for writing GUI application as far as functionality. There are tried-and-true toolkits such as GTK and QT and emerging ones such as Fyne and Gio. The former being more polished but with an extra layer of non-Go code between the app and the graphics layer and a higher learning curve. The latter's tooling, visualization documentation and functionality are less developed.
Where all of the options fall behind some other languages is in its developer friendliness in the form of documentation.
GTK do have a lot of documentation and many users who have posted answers on forums, but the documentation is based on another programming language.
Gio and Fyne are more lacking in documentation and tutorials so it can be more frustrating for beginners looking to learning or find answers. Although the general concepts might be more easily understood since they aren't as big of a system as GTK.
All the toolkits I tried rely a lot of providing code examples as a form of teaching, but the examples aren't very well documented or discoverable making them less friendly to developers.
Binary size for my simple program are:
- command-line only ~6M
- command-line + GTK GUI ~9M
- command-line + Fyne GUI ~14M
GTK does require for the shared libraries to be available on the system (they aren't compiled into the above binary) so they will need to be bundled in.
It took me about a day to write the Fyne version and about 2 days for the GTK version. I also had to spend a day to figure out how to get both to compile and run on Windows.
There are actually many choices available to Go developers for building GUIs. I think the perception that Go isn't a "GUI" language could be because:
- A number of GUI projects have been abandoned.
- There is no single "blessed" GUI framework from the Go team.
- There are no fully native Go implementation of a GUI toolkit.
(1) I don't think this is unusual given the complexity of developing a GUI framework that there are a lot of abandoned GUI projects. What is more important is what is available that is actively maintained since there are always many abandoned projects in any language so don't let the noise give you the wrong impression.
(2) Although there are some languages that comes with a GUI toolkit as part of the language (e.g. Java, Swift), most language don't. Go can feel like its a "batteries included" language with its rich standard libraries (e.g. it basically comes with a HTTP server) so with no GUI options it could lead to the misconception that the Go team doesn't believe that Go should be used for GUI apps. However, a lot of languages don't have one either (C/C++, Python, etc.)
(3) This really depends at what is the definition of a fully native Go implementation:
- Can app developers everything in Go? Can it be written in an idiomatic way?
- Can the entire project just depend on the Go tool chain?
- Is the whole tech stack built with Go?
Having the whole stack be written in Go is not realistic. With the exception of C, every language at some point have to deal with the lower level of the system (whether it be the graphics subsystem or OS) that is written in another language).
Personally, as long as everything I write is in Go and only the Go tools are used than that is "native" enough for me. As an applications layer developer, I don't expect to be working on the GUI underpinnings that would require to combine languages and tool chains. That means there are plenty of options for Gophers (developers that uses Go ) and my evaluation criteria is on some subjective qualities such as how intuitive it is and whether it is easy to learn/use, and some quantitative attributes such as stability.
With this in mind, the most often mentioned options are Qt, GTK, Fyne and Gio. Between Qt and GTK, I chose GTK. Both are these are popular production-level GUI toolkits written in C/C++. The reason I picked GTK is that I use Linux and Gnome and the admittedly self-perception that installing GTK is easier then installing a Qt dev environment.
I also wanted to try either Fyne or Gio as these are two toolkits that were built with Go. Both rely on go-gl (which in turn depends on OpenGL) to deal with the graphics subsystem to draw the interface and widgets so they don't that extra layer between the app and graphics system being occupied by another framework like GTK and Qt.
The first GUI toolkit that I tried to look at is Gio. It wholeheartedly embraced everything Go and the latest-and-greatest. It allows compiling to desktops, mobile, and WASM (web assembly). It supports Go modules (common) and drops GOPATH support (uncommon). Its embrace of immediate mode GUI programming is kind of Go-like in its belief that it's not always necessary to give up control to a framework.
Installing Gio to be ready to use is very easy. Make sure the system already installed the wayland/X11 and OpenGL development libraries. A simple 1-line install from dnf, apt or whatever Linux package manager will likely suffice. Then it is a simply importing the package in your Go code and during the first compile, Go will pull down Gio and all its dependencies through Go modules.
However, I quickly moved away from Gio for a couple of reasons:
- It lacked documentation to help a new user understand how to use it and I found the existing documentation to poorly organized. It primarily relies on code examples and API comments and then leaves it to the users to figure out for themselves how to use it.
- While immediate mode gives more control to the developers, building GUIs is one area where there's enough complexity that I don't necessarily mind handing it off to a toolkit to take care of things. I wonder whether immediate mode is actually more useful to developers who build GUI tool kits then developers who use the tool kits.
I might come back to Gio some day when I have more time to learn it.
Fyne is a more standard retained-mode GUI tool kit that is easy to install. It is similar to Gio in that you just need to use your package manager to install the graphical development libraries and then just import Fyne to have it download all the necessary packages and dependencies. Unlike Gio, it also support the traditional GOPATH method if you don't use Go modules.
The document was much more comprehensive feature an quick beginning walk-through, tutorials and API documentation. What holds by Fyne a little is in the organization of the documentation which required me to do quite a bit of jumping between sections to understand something. For example, one section talks about a widget but it is somewhere else where it shows what the widget actually looks like.
I was able to put together a basic interface pretty quickly with Fyne thanks to its basic tutorials. While getting something working quickly is a plus, I'll admit that I did not find the graphical elements very attractive. It seems to be embracing material design in some form but feels like it's incomplete. Extending the look and feel is also difficult at the moment.
Although I mentioned that I got a working GUI up quickly, I was immediately met with a bug. The app would start and all the components would draw in the window before it would suddenly turn blank. Resizing or hovering over a particular widget would bring the interface back. I only saw this on my Linux system. I reported this to Fyne and got a response pretty quickly asking me for more info and some follow up questions. It's good that the Fyne developers are keeping an eye on bug submissions!
To compile and run on Windows basically requires installing Windows version of gcc. Fyne's install instructions gives 3 options (msys2+MingW-64, TDM, and Cywin) for GCC. I went with msys2 + mingw64 as msys2 is also the recommended way to install GTK.
Once msys2 was installed, I installed the mingw64 gcc package through the msys2 shell:
> pacman -S mingw-w64-x86_64-toolchain base-devel
Note: If you want to use the GCC outside of the MingW shell (e.g. with cmd.com), you need to add:
to the Windows PATH variable.
After getting MingW GCC installed, I tried to compile and promptly ran into a compilation error about undefined references. After much digging, I found the solution to be deleting the go-build cache that is in %USERPROFILE%/AppData/Local/go-build.
To use GTK 3 with Go requires gotk3 which provide Go bindings to GTK's APIs (including glib, gdk, and others). There is also go-gtk which provides GTK 2 binding.
gotk3 has installation instructions on its wiki. Installing on Linux and MacOS is very simple similar to Gio and Fyne. For Windows, as with Fyne, it requires installing msys2 + mingw-64.
Although GTK has extensive documentation and tutorials, it's mostly for C or Python. gotk3's documentation, unfortunately, consists of mainly of comment that is just the C function name. It doesn't even provide a link to the C documentation so you're required to find it yourself. For the few APIs that has it's own gotk3 comments, they dropped the C function name so you will have to figure what the Go function maps to.
gotk3 also follows the "read the code" school of teaching. Here they have a directory of example code but little explanation of what it is an example of of. The user is left to decipher all the example codes to form an idea of how the gotk3 works and what is available. What I ended up doing was to go through and learn GTK in C first and then try to map the concepts to the gotk3 APIs. This isn't the most friendly way to introduce a Gopher to GUI development with gotk3 but might be okay for a C GTK developer coming to Go.
Of course, on my very first compilation, I get an error message:
go: finding module for package github.com/gotk3/gotk3/gtk
go: found github.com/gotk3/gotk3/gtk in github.com/gotk3/gotk3 v0.5.0
../../firstname.lastname@example.org/gtk/gtk.go:5369:14: _Ctype_struct__GIcon can't be allocated in Go; it is incomplete (or unallocatable)
Fortunately, there was already a bug filed and a solution was already committed. I had to force Go to use a newer version of gotk3 then what's has been tagged as the stable version:
**Update for go 1.16 4/3/2021** Another bug came up when trying to use go 1.16 and it looks like a fix made it to the master branch so the same workaround for the previous bug will now also work.
In the project directory:
go get github.com/gotk3/gotk3/gtk@master
While getting GTK installed on Linux was trivial, it takes a bit more effort on Windows, but the GTK page is very clear. If you'll be doing everything within msys then there's not much more to do. If you want to use build in another terminal such as cmd, then you'll need to add the mingw bin path to the %PATH% variable.
There seems to a compatibility issue between gotk3 and GTK that requires remove the -Wl flag from gdk.3.0.pc which is captured in the gotk3 wiki for installing on Windows.