Difference between revisions of "Architectural overview"

From Inkscape Wiki
Jump to: navigation, search
(Main subsystems - User Interface Modules)
m (Edited for brevity and clarity.)
Line 3: Line 3:
 
==Main subsystems==
 
==Main subsystems==
 
Inkscape can be roughly subdivided into a few subsystems:
 
Inkscape can be roughly subdivided into a few subsystems:
* [[Display subsystem]] - contained in the <tt>src/display/</tt> directory of the source tree. It is responsible for rendering graphic primitives, displaying things on the screen, and providing the main canvas widget. It also dispatches events to tools.
+
 
* [[XML subsystem]] - provides classes to store the parsed XML of an SVG document. It is fairly generic and does not contain significant SVG-related functionality. The main feature that distinguishes it from e.g. libxml++ is that it provides notification about XML changes and undo functionality. The classes of this subsystem are garbage collected. Because the XML nodes were formerly C structures called <tt>SPRepr</tt>, the XML tree is sometimes called the "repr tree", and XML nodes "reprs" - a short form of "representation".
+
* [[Display subsystem]]. Responsible for rendering graphic primitives, displaying things onscreen, and providing the main canvas widget. Also dispatches events to tools.  Contained in the <tt>src/display/</tt> directory of the source tree.  
* [[Object tree]] - implements a mapping from the XML to display primitives, and provides a hierarchy of objects that can be modified using the tools. This is where the bulk of Inkscape's functionality is contained. This system is 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 <tt>updateRepr()</tt> needs to be explicitly called.
+
* [[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 <tt>libxml++</tt>) are notifications about XML changes and undo functionality. This subsystem is garbage-collected. Because XML nodes were formerly C structures called <tt>SPRepr</tt>, the XML tree is sometimes called the "repr tree", and XML nodes "reprs" (short for "representation").
* [[Tools subsystem]] - provides tools, internally called event contexts, that process input events happening on the canvas and translate them into document changes. This subsystem is based on GObject, dispersed in the <tt>src/</tt> directory and several subdirs. Files that contain event handling code end with <tt>-context.cpp</tt>.
+
* [[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 <tt>updateRepr()</tt> must be explicitly called.
* [[Extension subsystem]] - allows Inkscape to use third-party extensions without modifying Inkscape's code. Currently extensions can provide additional input and output formats, effects, path effects and printing backends.
+
* [[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 <tt>src/</tt> directory (and several subdirectories). Files with event handling code end with <tt>-context.cpp</tt>.
* [[Preferences subsystem]] - this small, but relatively self-contained piece of code provides a shared storage for all of Inkscape's user settings. It keeps the parsed XML tree of the preferences file, but it's not directly accessible - the intent is to separate the preferences implementation (which in future might not be based on an XML file) from the API used to access them. It is contained in <tt>preferences.cpp</tt>
+
* [[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.
* [[User Interface Modules]] - contains specific Inkscape dialogs, widgets, tools and more.
+
* [[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 <tt>preferences.cpp</tt>
 +
* [[User Interface Modules]].  Dialogs, widgets, tools, and more.
  
 
==How Inkscape starts==
 
==How Inkscape starts==
Line 19: Line 20:
  
 
==Historical note==
 
==Historical note==
Inkscape is derived from an earlier vector drawing program called Sodipodi. Sodipodi was written entirely in plain C using GObject, 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. The long-term goal is to convert GObject-based code to regular C++ objects, but in the meanwhile some knowledge of GObject is needed to develop Inkscape.
+
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.  For the present, however,  some knowledge of GObject is needed to develop Inkscape.

Revision as of 14:05, 21 July 2010

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

Main subsystems

Inkscape can be roughly subdivided into a few subsystems:

  • 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.
  • 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.
  • 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. First, the main() function is called. On Windows, it is called from a WinMain() stub, so that the command prompt is not displayed.
  2. main() determines whether Inkscape was run in command-line mode or in graphical mode.
  3. Based on that decision, sp_main_console() or sp_main_gui() is called. Both those functions call sp_common_main(), which handles parameter parsing. Parameters are parsed into a lot global variables (needs to be heavily refactored).
  4. An Inkscape::NSApplication::Application object is instantiated. This object is an unfinished attempt at converting top-level Inkscape structures to C++ classes. It creates the legacy Inkscape::Application structure and creates SPDesktops for each opened document. (SPDesktop, "desktop" for short is a window used to edit a document - the main window you see when you start Inkscape.)
  5. Finally, the created desktops are shown.

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. For the present, however, some knowledge of GObject is needed to develop Inkscape.