Future Architecture

Goal

An easier to maintain Inkscape with a more flexible GUI and the possiblity of a headless Inkscape.

Problem

Inkscape's code is very convoluted. In particular the GUI code is embeded everywhere. One can't even open an SVG file without encountering GUI code (fixed!). Inkscape is also a signalling nightmare. It's hard to keep signals correct. Often the same function is called needlessly multiple times as a result of a simple action.

Means

Adopt Gio::Actions which separates GUI from actions. Use standard GTK3 classes. Rely on GTK3 active window tracking functionality.

Design

• Structure
  • The application owns documents and handles read/write/export via actions.
  • Each document has one or more views.
  • Each view has:
    • A document link.
    • An independent selection.
    • An independent transform. (Canvas to document transform if a canvas is present, identity matrix if not.)
• Application:
  • Keeps a map indexed by document to vectors of windows. A vector is used to update windows in response to document changes.
  • A vector of windows can be empty (as in the case of a headless Inkscape).
  • Keeps pointers to (updated when focus window changed or new document read-in [headless]):
    • Current document
    • Current selection
    • Current view
• Windows:
  • There are two types of window:
    1. Document Windows (e.g. Desktops).
    2. Dialog dock windows.
  • Each window (document or dock) is connected to one view and thus one document.
  • Each document window is connected to a particular view instance.
  • Each dock window is connected to the view of the most recent in-focus document window.
  • Each window handles updating the canvas and dialogs it contains in response to document changes.
  • A headless Inkscape has its own view (and thus selection) not linked to a window.
• Actions
  • Actions trigger changes to documents, preferences, etc.
  • Document actions work directly on a document (e.g. change viewbox) or a selection.
  • Application actions defined is separate files in a Gio::Application (base class of Gtk::Application) to allow a Gtk independent application. (IN PROCESS)
  • Command line should directly support actions. (DONE)
  • Command line options are short-cuts to actions. (DONE, mostly)
  • Processing and export actions from the command line should be stored in a vector so that they can be applied to multiple files. They must be processed after each file is opened. (DONE)

Steps

1. Move from Gtk::Main::run() to Gtk::Application. DONE
2. Move to Gtk::ApplicationWindow (InkscapeWindow). IN PROGRESS
3. Split the current code in inkscape.cpp between InkscapeApplication (Gtk::Application) and DocumentWindow (Gtk::ApplicationWindow) as appropriate.
4. Rewrite View to contain selections and not depend on GUI (move signals, message stack elsewhere). STARTED
5. Rewrite SPDesktopWidget: C++ify. Derive from Gtk::Box or embed directly in InksapeWindow. Rename to DesktopViewWidget (to match SVGViewWidget).
6. Replace our desktop switching signals/codes with code based on Gtk::Application's "active" window tracking ability.
7. Use Gio::Actions STARTED
   • Replace Verbs (mostly tied to desktop) by GUI independent actions.
   • Use actions in Command Line. MOSTLY DONE
   • Use actions in GUI (e.g. replace our custom GtkAction subclasses in Toolbars, replace custom widget classes).

Questions/Comments

Why is View derivied from GC::Managed, GC::Finalized, GC::Anchored? Do views really need garbage collecting?

 Used in ui/dialog/layer-properties.cpp
         ui/dialog/knot-properties.cpp
         ui/dialog/lpe-powerstroke-properties.cpp
         ui/dialog/lpe-fillet-chamfer-properties.cpp
         ui/widget/style-subject.cpp
         desktop.cpp

The application can monitor when a cursor crosses into a window and then update windows/dialogs. This eliminates the need for:

• ui/uxmanager
• ui/dialog/desktop-tracker

The code in ui/interface should be merged into InkscapeApplication or DocumentWindow or split out into more specific files.