BlueprintDOM

From Inkscape Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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.

View the diagram

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)

Additional information