Difference between revisions of "Future Architecture"

From Inkscape Wiki
Jump to navigation Jump to search
(Created page with "==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 par...")
(No difference)

Revision as of 13:22, 28 November 2018

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.)
  • 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
  3. Split the current code in inkscape.cpp between InkscapeApplication (Gtk::Application) and DocumentWindow (Gtk::ApplicationWindow) as appropriate.
  4. Start adding actions. DONE
  5. Use actions in Command Line and GUI. STARTED
  6. Rewrite View to contain selections and not depend on GUI (move signals, message stack elsewhere).
  7. Rewrite SPDesktopWidget: C++ify. Derive from Gtk::Box. Rename to DesktopViewWidget (to match SVGViewWidget).

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.