Odysseus consists of a number of "internal pages" for browser history, topsites, error messages and more. I mostly treat these as regular webpages to lower perceived complexity and because it can be useful.
Like many webpages these internal ones run a query against a relational database (SQLite here) and uses a templating language (one derived from Django's syntax). The difference though is that this relational database is gathered by your browser.
I opted to implement that templating language myself having decided I couldn't afford the startup cost or limited features of using an existing one. Furthermore segfaults pushed me into implementing it mostly from relative scratch, including (unfortunately) it's i18n engine.
It's quite simple interpretor with a two-pass lexer, a reentrant parser, and interpretation/parsing being done via dynamic dispatch (the template tag parsers may callback into the main parser).
The job of this templating language is very simple: take input from external datasources (implemented as an OO interface, may include SQLite, URIs, etc), and move it into place into an output stream (another interface, which may or may not simply wrap GIO).
For efficiency I've setup my Meson build system to use GResource to compile the templates into Odysseus's executable file, and I use GLib Bytes to avoid allocating and copying data around as it moves into place.
Some more minor points regarding templating:
1) data implicitly coerces between maps, iterables, numbers, bools, and numbers.
2) a `if` tag supports Boolean operators parsed via top-down operator precedence
3) the first pass lexer is a special split that treats quoted text as escaped. Very useful.
4) `with` proved to be useful as a building block or on it's own. Used by i18n & macros.
5) i18n reuses the same lexing to scan it's translation files, compiles to `with`.
The address bar uses a custom control for autocompletion (and will become more of a custom control itself) that sources it's completions from multiple inputs (browser history, DucDuckGo, some surprisingly subtle logic for when to imply https://, etc) and deduplicate them.
While to give a convenient experience I do have to branch outside of native text entry behavior, I avoid stretching it too much outside of what's familiar to GNOME/elementary users.
As for the browser chrome, that's unsurprisingly implemented using GTK+ 3, Granite, and other widgets found across elementary's projects.
The main challenge here is switching between which tab/WebView the "headerbar" (GTK's term for a combined toolbar+titlebar) represents, so that's encapsulated in it's own widget.
That UI consists mostly of toolbar buttons, with drop down menus (activated on hold-/right-click) to stuff the power-features in.
Each of these menu items and buttons are constructed, complete with any keyboard shortcuts, (mostly) in a single call each. Really helps it to read more declaratively.
This all comes together to leave the focus on the web, creating a simple yet powerful UI.
The chrome is little more than what elementary (and GNOME3) users are familiar with as standard window decorations. And additional navigation aids are unobtrusively implemented as extensions to the autocompletion or as internal webpages.
Adrian Cochrane