Using Go, how should I access window components in traditional inheritance based GUI Frameworks?

Question

I am doing some experimental work using GTK bindings for Go.

As with most GUI frameworks, a GTK GUI app generally spawns a main window and the application's work is done within the context of that window.

When you write a GTK GUI app in C++, you inherit from the framework window class - gtk.Window - and declare the other GUI components for your app as public members of your inherited window class (or use public access methods in your window class). That way they can be manipulated by a window controller class. which addresses them by name as members of your window class. You simply pass a pointer to your main window into the controller class and manipulate its members by writing mWindow.MyWidget.text="text", etc. Again, AFAIK, most GUI applications are designed similarly, regardless of the GUI framework being used.

However, since Go does not support inheritance, this option is not possible: When you instantiate additional GUI components in a Go-Gtk window, they are self standing variables, not members of the parent window class - they don't "live" in a container class. This means that your GUI controller class would have to access each component in the main window individually, with no cohesive structure or single reference to refer to. This compromises readability and good code organization, IMO - forces your code to be somewhat poorly structured.

I believe the solution to this problem in Go would be to declare a struct/interface that will serve as a container for all the main window's GUI components. That interface would publish access methods for the components and could be passed to a GUI controller unit for manipulating its members.

I need to know if there is a standard idiomatic Go design pattern for such a task, or what would be considered the correct approach to this issue using Go.

I understand that Go is designed to be a systems programming language, not really designed with frontEnd development in mind, but I have heard it said that "every good systems language will end up being used for applications", and there is no better systems language out there today than Go - the proof is that many Go bindings for GUI frameworks and other application tasks are surfacing. Look no further than A list of Go projects.

I guess the takeaway from all this is that Go is not designed to make it easy to develop desktop GUI apps, which are a dying breed.

Answer 1

You're asking how one might group a set of things into a collection, such that a controller can access all of them. You note that in C++, one would make this collection a subclass of gtk.Window. In go, there's no classes or type hierarchies, but otherwise the solutions are similar.

The solution is just to define a struct. Perhaps something like this:

type MainWindow struct {
    Win         *gtk.Window
    RedButton   *gtk.Widget
    GreenButton *gtk.Widget
}

A controller for the window can access any of the fields, without additional methods or accessors being needed:

type MainController struct {
    W *MainWindow
    other fields...
}

func (mc *MainController) DoSomething() {
    mc.W.RedButton.MakeVisible(true)
    mc.W.GreenButton.MakeVisible(false)
}

The methods here are just for illustration, obviously.

Answer 2

If I had to write an application with a GUI in Go, i would completely decouple the GUI part from the application part. An example of such approach is the GTK Server.

Only, you don't need a separate process to handle the GUI: you can do that in a goroutine, that communicates with the rest of the application using channels, the same way the Gtk Server uses sockets/pipes/message queues.

I don't know of anybody who used this approach, and I used it myself only in a toy program that builds a mimimalistic Tk GUI (used Tk because has a built-in interpreter and didn't know yet of gtk-server). But this would be for me the idiomatic way to build a GUI application in Go.