Difference between revisions of "SubsystemRearchitecture"

From Inkscape Wiki
Jump to navigation Jump to search
 
(10 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{outdated}}
{{DevDiscussion}}
== Subsystems Summary ==
== Subsystems Summary ==


Line 63: Line 65:
== Rearchitecturing Translation Map ==
== Rearchitecturing Translation Map ==


This shows how items in the current block diagram (http://www.inkscape.org/doc/) would be  
This shows how items in the [http://www.inkscape.org/doc/devdocs.php current block diagram] would be  
converted into the new subsystem architecture.
converted into the new subsystem architecture.


Line 69: Line 71:
  GUI
  GUI
   Dialogs      -->  Inkscape::UI::Dialogs
   Dialogs      -->  Inkscape::UI::Dialogs
   Widgets      -->  Inkscape::UI::Widgets, GtkDrawmm
   Widgets      -->  Inkscape::UI::Widgets, [[GtkDrawmm]]
   XML Editor    -->  Inkscape::UI::Dialogs
   XML Editor    -->  Inkscape::UI::Dialogs
  View            -->  Inkscape::UI
  View            -->  Inkscape::UI
Line 82: Line 84:
  libnrtype      -->  Pango
  libnrtype      -->  Pango
  SPSVGView      -->  SVG::Canvas
  SPSVGView      -->  SVG::Canvas
  SPSVGViewWidget -->  SVG::Canvas
  [[SPSVGViewWidget]] -->  SVG::Canvas
  src/svg/*      -->  eliminate
  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]]

Latest revision as of 14:52, 26 December 2012

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