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.