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.)
- 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).
- 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 (InkscapeWindow). IN PROGRESS
- Split the current code in inkscape.cpp between InkscapeApplication (Gtk::Application) and DocumentWindow (Gtk::ApplicationWindow) as appropriate.
- Rewrite View to contain selections and not depend on GUI (move signals, message stack elsewhere). STARTED
- Rewrite SPDesktopWidget: C++ify. Derive from Gtk::Box or embed directly in InksapeWindow. 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).
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.