BlueprintDOM
Motivation
The DOM interface is required to provide a scripting interface to Javascript (ECMAScript) and Python that matches the w3c standard. The DOM interface is quite large and therefore, the internal use would be practical, too. Currently, there is a lot of code that is replacable by DOM (CSS styling, SVG parsing). To avoid duplicate code, to clean up the existing mess and make it possible to implement new features without needing to rewrite a lot of code, the whole Inkscape should use the DOM to access the SVG properties.
Proposed architecture
The SVG representation is completely stored in the DOM. Every read or write access is done via DOM. Only to write or load an SVG file, the parsers and writers convert DOM to SVG or vice versa. The XML editor shall also use DOM, which reduces the editor complexiticy a lot. Internally, every DOM setter invokes a libsigc++ event, whose callback is defined in the event dispatcher module. Then, a renderer function (updateRendering or so) is called. A parameter containing a reference to the changed element ensures, that only the required area is updated.
Blue: already implemented, but not ready
Black: not yet working
Red: can be done later
Implementation steps
The w3c standard makes it possible to distribute the lot of work, because the DOM implementation is predefined. The developers just need to decide which conventions are used, e. g. for getters/setters.
1) implement the DOM
1) standalone SVG/CSS writer/parser module according to the w3c functions
1) modify renderer
2) event dispatcher (only a few ones are required to work)
3) merge everything together and make compilable
4) switch the rest to the new architecture (everything in the category “manual editing” + preference handling)