The main component in Odysseus’s “headerbar” the “addressbar”, which is basically just a GtkEntry. This afternoon I want to describe how it works.
GtkEntry does include a few “CSS gadgets” I make good use of in Odysseus, including a background progress bar (why don’t other browsers use that anymore?) and a single image on either side (with their own GdkWindow for capturing events). It also incorporates additional full-fledged widgets to aid touchscreen interaction, but I won’t discuss that further.
The size computation is quite naive, just using the configured natural and max sizes after converting from characters to pixels.
As for the actual text editing the GtkEntry exists for, it’s a bit of a process.
- A GtkGestureDrag and Pango helps to interpret mouse input, providing a means to set the text selection.
- Received keyboard input is interpreted via both an “Input Method” (for internationalization) and the CSS infrastructure (for special keys).
- The result text and operations are sent to the GtkTextBuffer, serving as the widget’s model.
- The output is rendered via Pango (which’ll cover tomorrow).
A GtkGesture very simply is a class which abstracts away a widget’s “event” signal, and GtkGestureDrag is a trivial subclass which triggers it’s own signals while a mouse button (or finger) is down. A signal is a GObject construct for event-driven software.
A GTK Input Method (class GtkIMContext) is a class dynamically loaded from a configurable location. Though there is a simple one bundled with GTK that merely implements escape sequences for typing extended Unicoded characters.
And finally a GtkEntryBuffer (the Model of MVC underlying GtkEntry) simply memcpys text around in it’s memory segment, taking care to zero-out deleted text in case it’s a password. And ofcourse it needs to track how much memory it’s currently using, so it can enlarge that memory segment as needed.