Difference between revisions of "Future Architecture"
(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...")
Revision as of 13:22, 28 November 2018
An easier to maintain Inkscape with a more flexible GUI and the possiblity of a headless Inkscape.
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.
Adopt Gio::Actions which separates GUI from actions. Use standard GTK3 classes.
- 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.)
- There are two types of window:
- Document Windows (e.g. Desktops).
- 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.
- There are two types of window:
- 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)
- Move from Gtk::Main::run() to Gtk::Application. DONE
- Move to Gtk::ApplicationWindow
- Split the current code in inkscape.cpp between InkscapeApplication (Gtk::Application) and DocumentWindow (Gtk::ApplicationWindow) as appropriate.
- Start adding actions. DONE
- 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).
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:
The code in ui/interface should be merged into InkscapeApplication or DocumentWindow or split out into more specific files.