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...")
 
Line 45: Line 45:
# Move to Gtk::ApplicationWindow
# Move to Gtk::ApplicationWindow
# Split the current code in inkscape.cpp between InkscapeApplication (Gtk::Application) and DocumentWindow (Gtk::ApplicationWindow) as appropriate.
# Split the current code in inkscape.cpp between InkscapeApplication (Gtk::Application) and DocumentWindow (Gtk::ApplicationWindow) as appropriate.
# Start adding actions. DONE
# Rewrite View to contain selections and not depend on GUI (move signals, message stack elsewhere). STARTED
# Use actions in Command Line and GUI. STARTED
# Rewrite View to contain selections and not depend on GUI (move signals, message stack elsewhere).
# Rewrite SPDesktopWidget: C++ify. Derive from Gtk::Box. Rename to DesktopViewWidget (to match SVGViewWidget).
# Rewrite SPDesktopWidget: C++ify. Derive from Gtk::Box. Rename to DesktopViewWidget (to match SVGViewWidget).
# Replace our desktop switching signals/codes with code based on Gtk::Application's "active" window tracking ability.
# 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==
==Questions/Comments==

Revision as of 14:45, 29 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. 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. 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.