As part of the C++-ification, we need to introduce namespaces. In addition, we wish to reorganize the codebase to suit our longer term architectural plans, such as conversion to Cairo, Pango, and Gtkmm, introduction of our API and modular extension system, and provision to the community of an SVG Canvas.
Here is a proposal for a new architecture that incorporates these elements. It also shows how to map from the current architecture.
This is presented as a proposal to spark discussion, and will be updated with any feedback you provide. Please ask questions of anything that is unclear. Once we have a rough concensus on it, we will formalize it and can proceed with the work.
I've also posted this to Wiki as "SubsystemReachitecture" if you'd prefer to comment upon or work on the document there.
Bryce
== 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 ==
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 --> libvgcanvas Module --> Inkscape::Module Display --> Cairo libnr --> Cairo libnrtype --> Pango SPSVGView --> SVG::Canvas SPSVGViewWidget --> SVG::Canvas src/svg/* --> eliminate