SubsystemRearchitecture

Subsystems Summary

Namespace                  Link   Audience   Lib Name        Directory
Inkscape::Document         C++    Internal   libinkdoc       src/document
Inkscape::Extension        C++    Internal   libinkext       src/extension
Inkscape::UI               C++    Internal   libinkui        src/ui/
Inkscape::UI::Dialogs      C++    Internal   libinkuidlg     src/ui/dialogs
Inkscape::UI::Widgets      C++    Internal   libinkuiwdg     src/ui/widgets
SVG::Canvas                C/C++  Community  libsvgcanvas    src/svgcanvas
SVG::DOM                   C/C++  Community  libsvgdom       src/svgdom

Cairo                      C      (dep)      libcairo        (external)
Pango                      C      (dep)      libpango        (external)

Descriptions of Proposed Subsystems

Inkscape::Document - This is a high level wrapper for the application's document model, and basically just subclasses SVG::DOM, adding some Inkscape-specific aspects.

Inkscape::Extension - This namespace encapsulates the various mechanisms for extending the Inkscape application, including import/export mechanisms, GUI plugins, stdin/stdout programs, language bindings, etc.

Inkscape::UI - Namespace for Inkscape-specific User Interface elements, including view & controller aspects.

Inkscape::UI::Dialogs - dialogs for Inkscape

Inkscape::UI::Widgets - widgets that are particular to Inkscape; if they seem to be of general use, they will be migrated into a separate library to share with other applications in a more general fashion.

SVG::Canvas - A distinct deliverable Inkscape provides to the Open Source community for implementing an SVG-based drawing surface, for use in other applications. Initially will be made up of similar subsystems shared with Inkscape but be a separate package, but ultimately should be a packaged dependency of Inkscape.

SVG::DOM - This is a Document Object Model for SVG documents. It is the key dependency for SVG::Canvas, and thus is also something Inkscape provides externally to the Open Source community. Internally, it is implemented as a C++ class hierarchy, but externally can be linked to using either C or C++ style linkage. The externally presented API would be standard DOM.

Cairo - Switching to Cairo will occur late in the rearchitecturing process. We need to ensure Cairo provides the capabilities already present in libnr. Completing other areas of rearchitecting will help get the codebase organized for conversion of it to Cairo, without taking undue risk in adopting a different underlying renderer.

Pango - Conversion to Pango from libnrtype may be worth doing earlier than Cairo since the existing text system lacks many needed features, however this will need to be researched in more depth to determine the feasibility and cost/benefit. Unless a clear benefit is identified to performing the change early, we should conduct the change along with the Cairoification.

Rearchitecturing Translation Map

This shows how items in the current block diagram (http://www.inkscape.org/doc/) Generic Viagra Generic Propecia Generic Glucophage Generic Lipitor would be converted into the new subsystem architecture.

Existing             Proposed
GUI
  Dialogs       -->  Inkscape::UI::Dialogs
  Widgets       -->  Inkscape::UI::Widgets, GtkDrawmm
  XML Editor    -->  Inkscape::UI::Dialogs
View            -->  Inkscape::UI
SPAction        -->  Inkscape::UI
verbs           -->  Inkscape::UI
shortcuts       -->  Inkscape::UI
SVG DOM         -->  Inkscape::Document, libsvgdom
SVG Canvas      -->  libsvgcanvas
Module          -->  Inkscape::Module
Display         -->  Cairo
libnr           -->  Cairo
libnrtype       -->  Pango
SPSVGView       -->  SVG::Canvas
SPSVGViewWidget -->  SVG::Canvas
src/svg/*       -->  eliminate