## The Editor Widget

For every xml node in the document, there is a CongEditorNode for each editor_widget3. There is a class hierarchy of CongEditorNode subclasses, so, for instance, there's a CongEditorNodeElementStructuralTag which is used for structural tags, and a CongEditorNodeComment for comments. This way, we only have to figure out what type a node is once, rather than every time we visit it, plus we can store useful state in the CongEditorNode objects. For example, in a CongEditorNodeText, we store a PangoLayout.

There is also a collection of CongEditorArea objects. These form a hierarchical tree of rectangular areas which divide up the space allocated to the widget. They know how to draw themselves, can be clicked on, handle size negotiation etc. They are a little bit like a lightweight version of GtkWidgets, although the analogy isn't perfect.

CongEditorArea objects are what you see and click on when interacting with the editor_widget3, although not all of them are visible (e.g. CongEditorAreaComposer which exists purely to manage the sizing of its children).

CongEditorNode objects work behind the scenes. They are responsible for creating CongEditorArea objects to represent themselves.

There are a few other classes involved: CongEditorAreaFlowHolder, and CongEditorChildPolicy. These are responsible for generating paragraph-like areas, which the editor nodes "pour" their CongEditorAreas into. This allows us to get the nice underlines, which is achieved by using a PangoLayout for every text node, splitting all the PangoLayoutLines into separate CongEditorArea objects, and then merging them, together with a few extra CongEditorAreas.

If you want to see the CongEditorAreas, then go to src/cong-editor-area.c and play around with the #define settings; in particular DEBUG_RENDER_ALLOCATIONS can be used to render rectangles to indicate all of the bounding boxes of the CongEditorAreas.

## Child Policies