-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Drivers
A driver in Fyne is responsible for providing all of the operating system specific implementation and rendering detail of the API to create a complete application. There are currently 2 drivers available desktop and test.
The main Fyne driver uses the EFL to render a user interface. This graphical stack supports many operating systems and provides Windows, Linux and macOS support for the standard Fyne installation.
You can see this in use in the example applications - invoking the desktop.NewApp()
is setting up the desktop/EFL driver. From this point onwards any call like app.CreateWindow()
will call into the EFL code for operating system specifics.
import "github.com/fyne-io/fyne/desktop"
The test driver is really helpful for unit testing the Fyne code and also application logic. This driver never renders anything to screen but executes all other code as expected. This driver can be used without invoking an application constructor, if you include the following import in your _test.go file you can simulate an application in memory.
import _ "github.com/fyne-io/fyne/test"
Over time it may become useful to add a new driver or migrate portions of an existing one to new technologies. For example a new driver may enable Fyne to run on a mobile device or in a web browser, and an update to the existing desktop driver may allow native render calls on Windows to avoid the EFL dependency.
A new driver would need to implement all of the fyne.Driver
interface which is mainly responsible for managing native windows within an application. Every window that a driver creates will need to contain a canvas, and this is the link to the core responsibility of a driver - rendering.
A driver must be capable of rendering all the types of canvas object defined in the canvas package (currently line, rectangle, text and image (both bitmap and SVG)). Widgets and GUIs are drawn using these primitive objects and so the driver does not need to have any widget rendering programmed in. It will need to traverse the object tree from each Window instance and so must understand how fyne.Container
and fyne.Widget
wrap child objects. Layouts are not part of the driver, all the positioning is handled in Go code and pushed into the object state ready to be rendered.
A driver must also handle user input, typically mouse, keyboard and touch screen. It should create the appropriate fyne.KeyEvent
and fyne.MouseEvent
objects and send them to the objects that are set up to handle the events.
Take a look at the desktop/*.go package to see how this has been implemented for the current driver.
To work on adding a new renderer to an existing driver is going to be less work, but not much. It would need to cover the canvas requirements in the section above - draw the primitive types in the correct place and handle user input. To include this in the existing driver would require build tags or OS specific files - if adding support for another operating system note that there is a top level interface, fyne.Application
, which may need to be implemented as well.