Architectural overview

This is a high-level overview of how Inkscape works.

See doc/architecture.txt in the code repository for another (dated) overview.

Main subsystems

Inkscape can be roughly subdivided into these subsystems:

XML subsystem

Classes to store the parsed XML of an SVG document. Fairly generic, and doesn't contain significant SVG-specific functionality. The main distinguishing features (from something like libxml++) are notifications about XML changes and undo functionality. This subsystem is garbage-collected. Because XML nodes were formerly C structures called SPRepr, the XML tree is sometimes called the "repr tree", and XML nodes "reprs" (short for "representation").

Object tree

This is where the bulk of Inkscape's functionality is contained. Implements an XML-to-display primitive mapping, and provides an object hierarchy that can be modified using the tools. Based on GObject. Each document has an object tree and an XML tree. Changes in the XML tree are automatically propagated to the object tree via observers, but not the other way around—a function called updateRepr() must be explicitly called.

Display subsystem

Responsible for rendering graphic primitives, displaying things onscreen, and providing the main canvas widget. Also dispatches events to tools. Contained in the src/display/ directory of the source tree.

Tools subsystem

Processes input events on the canvas and translates them into document changes. Tools are called event contexts internally. This subsystem is based on GObject, dispersed in the src/ directory (and several subdirectories). Files with event handling code end with -context.cpp.

Extension subsystem

Allows third-party extensions without modifying Inkscape's code. Currently, extensions may provide additional I/O formats, effects, path effects, and printing backends.

Preferences subsystem

Provides a shared storage for all of Inkscape's user settings. Small but relatively self-contained. Keeps the parsed XML tree of the preferences file (but it's not directly accessible). The intent is to separate preference implementation (which might not be based on an XML file in the future) from the API used to access them. Contained in preferences.cpp

User Interface Modules

Dialogs, widgets, tools, and more.

How Inkscape starts

1. main() is called, and determines whether Inkscape was run in graphical mode or command-line mode.
   1. On Windows: A WinMain() stub calls main() so that the command prompt is not displayed.
2. Based on the decision, either sp_main_gui() or sp_main_console()is called.
   1. Both call sp_common_main(), which handles parameter parsing. Parameters are parsed into several global variables. (Yes, this needs to be heavily refactored!)
3. An instance of Inkscape::NSApplication::Application is created.
   1. This object is an unfinished attempt at converting top-level Inkscape structures to C++ classes. It creates the legacy Inkscape::Application structure and creates an instance of SPDesktop for each open document. (SPDesktop is a window used to edit a document—the main window you see when you start Inkscape. Sometimes simply called “desktop” for short.)
4. The created desktops are shown.

Ta-Da!

Historical note

Inkscape is derived from an earlier vector drawing program called Sodipodi.

Sodipodi was written entirely in plain C using GObject. GObject is the C object system used by GTK+.

Writing and maintaining GObject code is cumbersome, because C lacks any syntax support for this system. There are still many places that use old GObject-based code (notably the tools and the SPObject tree).

An important long-term goal is to convert all GObject code to regular C++ objects. This goal has been addressed for the most part with 0.91.