Architecture
The Fyne toolkit is split into 2 projects - "fyne" (the main developer API) and "fyne/driver" (the operating system specific code and renderer for desktop environments).
The high level API for the Fyne UI and App toolkit. This project defines the main API that developers will interact with, it defines the interaction for windows, widgets and canvases. Layouts, user interaction and themes are all defined within this API.
The application UI is defined by way of various Widgets or CanvasObjects. Containers exist to hold multiple widgets or objects and the arrangement of these sub-objects is controlled by various Layouts. The tree of objects could be serialised in and out of static files such as json if developers or tool creators find that easier to work with than the main API.
The core API is pure Go which makes it very fast for development, testing and highly portable.
The canvas package contains the APIs for managing graphical elements that can be drawn to a canvas. Objects in this package are manipulated through the fields they expose. Constructor functions are available to create objects for drawing.
If you change the properties of a visible object after creation you should probably call canvas.Refresh(obj)
to request that it is redrawn.
Widgets are the main part of the Fyne GUI - most elements you use within a window are defined in this package. Like the canvas package you can use properties of the objects to control their logical state. Unlike the canvas package these elements hide the graphical details from the API so that implementation details do not mix with the intent of widget interactions.
Calls to a widget are typically function based rather than properties, when used in this way the UI will automatically update. If you change fields in a widget be sure to call canvas.Refresh(widget) after you are done (this can be more efficient if you want to change many fields in a widget at the same time).
The test package helps to write GUI unit tests or even to support Test Driven Development. Utility functions such as test.Tap and test.Type(string) support simulating user input without having to directly manipulate widgets under test. This can be seen in action in our tutorial video 4. Test Driven Development.
The driver package contains platform specific driver extensions. If you use these make sure that the code is guarded with if statements or a type check - failing to do so may cause runtime crashes.
Extensions for running on desktop including extended keyboard support and detailed mouse handling information.
This area contains helpful code for implementing the Fyne toolkit that is not exposed to regular developers.
Sometimes APIs may start out in the internal package for testing before being moved to a publicly exported API.
This internal package contains the drivers which are responsible for showing Fyne applications and handling user input and system information. There are two drivers - glfw (that uses OpenGL through go-gl and glfw) and gomobile (which uses GLES and the gomobile project) (we may look at other Drivers in the future). The drivers provide modules for various operating systems and driver combinations such as 3D acceleration.
Code in this area is a mix of Go, CGo and C which means that it is less portable. Any feature additions need to support, at least, Fyne's Supported Platforms.
The painter packages contains modules that actually render the contents of a Fyne canvas. There are currently two painters, gl (which draws using OpenGL or GLES) and software (which manipulates graphics directly in memory). The Gl package is hardware accelerated and is used by most of the Fyne drivers - it requires CGo to compile, but it is considered worth the complexity due to it's performance. The software painter is useful for testing and generating image captures through other automated scripts - it provides support for Go Playground previews and also the images in our documentation.
Remember that with all of the APIs and developer facing code we aim to make it easy and fast to build great looking applications. Some of the complexity internally is necessary to make that happen. Nonetheless this core code is well tested and must be maintainable and extensible by any new developers who would like to join the project.