A frontend must provide three GNU Makefile fragments (these will be
included from the core Makefile):
-`Makefile` - This is used to extend CFLAGS, CXXFLAGS and LDFLAGS variables as required. The executable target is set with EXETARGET and the browser source files are listed in the SOURCES variable
-`Makefile.defaults` - allows setting frontend specific makefile variables and overriding of the default core build variables.
-`Makefile.tools` - allows setting up frontend specific build tooling (as a minimum a tool for the package configuration in PKG_CONFIG)
Source code modules can be named as the devloper desires within the
frontend directory and should be added to the SOURCES variable as
Generally the entry point from the OS is the `main()` function and
several frontends have a `main.cpp` where some have used `gui.c`.
The usual shape for the `main()` function is a six step process:
1. The frontends operation tables are registered with NetSurf
2. The toolkit specific initialisation is performed (which may involve calling NetSurf provided utility functions for support operations like logging, message translations etc.)
3. Initialise the NetSurf core. After this point all browser functionality is available and registered operations can be called.
4. Perform toolkiit setup, usually opening the initial browsing window (perhaps according to user preferences)
5. Run the toolkits main loop while ensuring the Netsurf scheduled operations are also run at teh apropriate time.
The fetch operations allow the built in scheme fetchers (file, about, resource) to obtain additional information necessary to complete their operation.
The two mandantory operations are:
-`filetype` - allows the file scheme to obtain a mime type from a file path e.g. `a.file.name.png` would result in `image/png`
-`get_resource_url` - maps resource scheme paths to URL e.g. `resource:default.css` to `file:///usr/share/netsurf/default.css`
This is availble as a single commit (`git show 28ecbf82ed3024f51be4c87928fd91bacfc15cbc`) in the NetSurf source repository. Alternatively it can be [viewed in a web browser](https://git.netsurf-browser.org/netsurf.git/commit/?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc).
The [frontends/Makefile.hts](https://git.netsurf-browser.org/netsurf.git/diff/frontends/Makefile.hts?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc)
In our example program entry is the classical `main()` in the [main.cpp](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/main.cpp?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc) module.
The function `nsfltk_run()` runs the toolkit event loop. In this case it is using the generic scheduleing in the [misc.cpp](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/misc.cpp?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc) module to ensure callbacks get made at the apropriate time.
Amongst all the boilerplate of the default implementation the only novel code is in the window operation table in the [window.cpp](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/window.cpp?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc) module.
implemented in [plotters.cpp](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/plotters.cpp?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc)
The previous section outlined the absolute minimum
implementation. Here we can exmaine some next steps taken to extend
the frontend.
## Improving the user interface
The example discussion is based on a commit (`git show bc546388ce428be5cfa37cecb174d549c7b30320`) in the NetSurf source repository. Alternatively it can be [viewed in a web browser](https://git.netsurf-browser.org/netsurf.git/commit/?h=vince/fltk&id=bc546388ce428be5cfa37cecb174d549c7b30320).
This changes a single module `window.cpp` where the `NS_Window`,
`NS_Widget` and `NS_URLBar` classes are used to create a basic
browsing interface.
The static window operation functions are moved inside the `NS_Window`
class and the `gui_window` structure is used to obtain an instance
allowing normal methods to be called to implement functionality. This
is purely to make the C++ code more idiomatic and obviously would be
handled differently in other languages.
The `NS_Window` constructor builds additional widgets to just the
browser drawing widget. It creates:
- a URL bar widget containing some navigation buttons and a widget to show the current url
- a vertical scrollbar
- a horizontal scrollbar
- a status text widget
The scrollbar widgets fltk callbacks (called when user interacts with
the scrollbar) call a method on the `NS_Widget` allowing it to track
the current scroll offsets which are subsequently used in the drawing
and user input handling methods.
## Improving rendering
Up to this point the rendering has been minimal and the text in a
single face and size with incorrect width measurement. There was no
proper handling of plotting styles and colours.
## Implementing bitmap rendering
There was no bitmap rendering so no pretty pictures.
## Implementing the user messages API
This immediately allows the browser to use the existing language
translations for many internal strings.
## Implementing a user settings dialog
Implementing a way for the user to change configuration options
without having to edit a configuration file greatly improves the
perceived functionality.
## Implementing corewindow
The [core window interface](docs/core-window-interface.md) allows a
frontend to use inbuilt rendering for several interfaces gaining a
great deal of functionality for very litte code. This one interface
set gives a cookie viewer,a local and global history viewer and a