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...") |
|||
(9 intermediate revisions by the same user not shown) | |||
Line 7: | Line 7: | ||
Inkscape's code is very convoluted. In particular the GUI code is | Inkscape's code is very convoluted. In particular the GUI code is | ||
embeded everywhere. One can't even open an SVG file without | embeded everywhere. One can't even open an SVG file without | ||
encountering GUI code. Inkscape is also a signalling nightmare. | encountering GUI code (fixed!). Inkscape is also a signalling nightmare. | ||
It's hard to keep signals correct. Often the same function is called | It's hard to keep signals correct. Often the same function is called | ||
needlessly multiple times as a result of a simple action. | needlessly multiple times as a result of a simple action. | ||
Line 13: | Line 13: | ||
==Means== | ==Means== | ||
Adopt Gio::Actions which separates GUI from actions. Use standard GTK3 classes. | * Adopt Gio::Actions which separates GUI from actions. | ||
* Move Inkscape's custom verbs to Gio::Actions. | |||
* Use standard GTK3 classes. | |||
* Rely on GTK3 active window tracking functionality. | |||
==Design== | ==Design== | ||
Line 23: | Line 26: | ||
*** An independent selection. | *** An independent selection. | ||
*** An independent transform. (Canvas to document transform if a canvas is present, identity matrix if not.) | *** 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). | |||
** Keeps pointers to (updated when focus window changed or new document read-in [headless]): | |||
*** Current document | |||
*** Current selection | |||
*** Current view | |||
* Windows: | * Windows: | ||
** There are two types of window: | ** There are two types of window: | ||
Line 43: | Line 53: | ||
# Move from Gtk::Main::run() to Gtk::Application. DONE | # Move from Gtk::Main::run() to Gtk::Application. DONE | ||
# Move to Gtk::ApplicationWindow | # Move to Gtk::ApplicationWindow (InkscapeWindow). IN PROGRESS | ||
# Split the current code in inkscape.cpp between InkscapeApplication (Gtk::Application) and | # Split the current code in inkscape.cpp between InkscapeApplication (Gtk::Application) and InkscapeWindow (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). | |||
# Rewrite View to contain selections and not depend on GUI (move signals, message stack elsewhere). | # Replace our desktop switching signals/codes with code based on Gtk::Application's "active" window tracking ability. | ||
# Rewrite SPDesktopWidget: C++ify. Derive from Gtk::Box. Rename to DesktopViewWidget (to match SVGViewWidget). | # 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== | ||
Line 65: | Line 78: | ||
* ui/dialog/desktop-tracker | * ui/dialog/desktop-tracker | ||
The code in ui/interface should be merged into InkscapeApplication or DocumentWindow or split out into more specific files. | The code in ui/interface should be merged into InkscapeApplication or DocumentWindow or split out into more specific files. IN PROGRESS |
Latest revision as of 12:41, 24 January 2019
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 (fixed!). 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.
- Move Inkscape's custom verbs to Gio::Actions.
- Use standard GTK3 classes.
- Rely on GTK3 active window tracking functionality.
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).
- Keeps pointers to (updated when focus window changed or new document read-in [headless]):
- Current document
- Current selection
- Current view
- Windows:
- 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
- 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
- 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 InkscapeWindow (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).
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. IN PROGRESS