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. 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.

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).
• 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.