Back

The GTKWindow, as GTKContainer/GTKBin, manages this "title_box" alongside it's main child, and tells internal code (including CSS styling and, for GTK3 which I'm currently running, the drawing routines) to iterate over both widgets. It's all pretty straightforward.

And for the GTKHeaderBar specifically the window propagates any changes to it's "title" property, to reside in the center of the headerbar by default.

The GTKHeaderBar itself meanwhile is a fairly normal GTKContainer.

The GTKHeaderBar itself functions will generate GTKButtons parsed from a configuration string (for elementary OS "close:maximize"), have their click events dispatch to GTKWindow methods (which in turn wraps GDK methods), and update them when the window state changes.

It also optionally manages an "application menu", title, and/or subtitle; but I don't use that in Odysseus.

These, and any children I provide, are tracked in a linked list, or a "custom_title" property.

However as a GTKContainer, the HeaderBar's main job is perhaps to compute it's children's layout and schedule the triggering event. A task it dispatches through a "CSS Gadget" (don't ask me why that's in there).

The first step of layout is to do a tree traversal computing the minimum and natural sizes for both width and height (queried in ideal order for widgets). Which here is a simple sum (horizontal) or max (vertical).

Given that we can easily compute size to distribute to the children...

Distributing the resulting size to the children turns out to be two-step process. First it needs to know how much space is left over, and then it needs to distribute that out equally to all children so have plenty of whitespace in which to drag the window.

This is essentially the same process used by the deprecated GTKBox.

Fin.