SubsystemRearchitecture
This page is outdated. It is kept for historical reasons, e.g. to document specific decisions in Inkscape development.
Subsystems Summary
Namespace Link Audience Lib Name Directory Inkscape::Document C++ Internal libinkdoc src/document Inkscape::Extension C++ Internal libinkext src/extension Inkscape::SVG::Object C++ Internal libinksvgobj src/svg/object/ 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::SVG::Object - This will include SPObject and its children
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 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 SPObject --> Inkscape::SVG::Object (and to /src/svg/object/)
SPRepr -> Inkscape::XML::Node SPReprDoc -> Inkscape::XML::Document SPReprAttr -> Inkscape::XML::AttributeRecord SPReprAction -> Inkscape::XML::Event SPReprEventVector -> Inkscape::XML::NodeEventVector