]> There is a single CongApp object representing the entire application; this owns a collection of CongPrimaryWindow objects, each represents one of the application's primary windows. A primary window corresponds to a particular CongDocument. In addition, the CongApp owns certain global resources, including the CongDispspecRegistry. A CongDocument is a wrapper around the libxml2 document tree, together with a cursor location, and a selection range. It references a CongDispspec. It is a GObject, and it emits signals when things change. There is also an earlier system, in which there are CongView structs which manually register themselves with CongDocument objects and receive all updates. This is now deprecated. A dispspec is a "display specification"; it is a way of looking up tags in the xml document and deciding if they are "structural" and hence should appear as big blocks in the view, or "spans", in which case they can merely be rendered as an underline. It also supports looking up icons to use, and, in theory, localisation of the tag names. The display specifications are generally loaded from ".xds" files, but can also be created at run-time. &cong-app; &cong-document; &cong-document-traversal; &cong-traversal-node; &cong-dispspec; &cong-dispspec-element; &cong-dispspec-registry; &cong-dtd; &cong-primary-window; A CongNodePtr is a libxml2 xmlNodePtr; originally it was something else, though. It's a node in the DOM tree of the document. Everything is stored in UTF-8 internally. There are some CongNode operations, and these are generally convenience wrappers around libxml2. A CongLocation is a small struct which identifies a "location" in the document (e.g. for storing the cursor location). It's got a pointer to a node in the document tree, together with an offset into the content of the node, which is only relevant for TEXT and COMMENT nodes. It's the number of bytes, rather than the number of characters. &cong-node; &cong-location; &cong-range; &cong-selection; All changes to a CongDocument should be done using CongCommand objects. Each CongDocument has a CongCommandHistory which stores all of the commands that have been applied to that command which can be undone, and all that can be redone. In order to modify the document, you should do something like this: CongCommand *cmd = cong_document_begin_command (doc, _("User-visible name of command"), NULL); cong_command_add_modification_do_something (cmd, param1); cong_command_add_modification_do_something_else (cmd, param2, param3, param4); cong_document_end_command (doc, cmd); All commands are built up of modifications, all of which break down into a small number of atomic modifications. Each type of modification corresponds to a subclass of CongModification, and contains enough information to be able to redo and undo the command As the atomic modifications are done/undone, they call the appropriate CongDocument methods which have the word "private" in their names e.g. cong_document_private_node_add_after. These emit signals which are listened to by the various views, widgets etc. The CongDocument also handles the signal by calling a correspong cong_node_private function e.g. cong_node_private_add_after, which actual makes the change to the libxml2 representation of the document. &cong-command; &cong-command-history; &cong-modification; &cong-node-modification; &cong-node-modification-add-after; &cong-node-modification-add-before; &cong-node-modification-make-orphan; &cong-node-modification-remove-attribute; &cong-node-modification-set-attribute; &cong-node-modification-set-parent; &cong-node-modification-set-text; &cong-modification-cursor-change; &cong-modification-selection-change; &cong-modification-set-dtd-ptr; 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 CongEditorNodeElementStructural 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. When working on layout code, it may help to turn up the font sizes so that everything is much larger on your screen. You can do this by editing src/cong-app.c and defining TEST_BIG_FONTS to be 1. &cong-editor-widget; &cong-editor-node; &cong-editor-node-comment; &cong-editor-node-document; &cong-editor-node-dtd; &cong-editor-node-element-span; &cong-editor-node-element-structural; &cong-editor-node-element-unknown; &cong-editor-node-element; &cong-editor-node-entity-decl; &cong-editor-node-entity-ref; &cong-editor-node-text; &cong-editor-node-unimplemented; &cong-editor-area; &cong-editor-area-bin; &cong-editor-area-border; &cong-editor-area-composer; &cong-editor-area-container; &cong-editor-area-entity-decl; &cong-editor-area-entity-ref; &cong-editor-area-expander; &cong-editor-area-labelled; &cong-editor-area-line; &cong-editor-area-pixbuf; &cong-editor-area-spacer; &cong-editor-area-span-tag; &cong-editor-area-structural-tag; &cong-editor-area-structural; &cong-editor-area-text-comment; &cong-editor-area-text-fragment; &cong-editor-area-text; &cong-editor-area-underline; &cong-editor-area-unknown-tag; &cong-view; &cong-tree-view; &cong-overview-view; The singleton CongApp object owns a singleton CongPluginManager. This in turn owns a collection of CongPlugin objects, each of which represents a plugin. In turn, these each contain a collection of CongService objects which they register with the program. The various subclasses of CongService are the various kinds of functionality offered by plugins to the progam. The plugins aren't actually compiled into separate dynamic libraries yet, but instead are all compiled into the main executable. Registration hooks are called manually within cong-fake-plugin-hooks.c. Our current plan is to move to a genuine plugin system by using the libgoffice library (when it is released). &cong-plugin; &cong-plugin-manager; &cong-service; &cong-service-tool; &cong-service-doc-tool; &cong-service-document-factory; &cong-service-editor-node-factory; &cong-service-exporter; &cong-service-importer; &cong-service-node-property-dialog; &cong-service-node-tool; &cong-service-print-method; &cong-fake-plugin-hooks; &plugin-admonition-node-element; &plugin-lists-area-listitem; &plugin-lists-node-element-listitem; &plugin-paragraph-area-paragraph; &plugin-paragraph-node-element-paragraph; &cong-attribute-editor; &cong-attribute-editor-cdata; &cong-attribute-editor-enumeration; &cong-attribute-editor-lang; &cong-attribute-wrapper; &cong-attribute-wrapper-check-button; &cong-attribute-wrapper-radio-button; &cong-dialog; &cong-glade; &cong-object; &cong-eel; &cong-eel-graphic-effects; &cong-enum-mapping; &cong-error-dialog; &cong-util; &cong-text-cache; &cong-progress-checklist; &cong-file-selection; &cong-edit-find-and-replace; &cong-ui-hooks; &cong-xpath-expression; &cong-font; &cong-graph; &cong-marshal; &cong-parser-error; &global; &cong-vfs; &tree_index;