Inkscape Canvas
This page is for discussions about how the Inkscape Canvas should be structured.
See also Future Architecture.
The key goals are:
- To allow for a modular Inkscape.
- To allow for multiple independent renderers (Cairo, OpenGl).
- To simplify the code by compartmentalizing functionality.
The current widget structure, post 1.0.x (with several container widgets missing):
- InkscapeWindow
- Desktop Widget
- Lots of toolbars
- Status Bar
- Palette
- Canvas Grid Widget
- Rulers
- Scrollbars
- Buttons
- Canvas (SPCanvas)
- Canvas Items/Groups (pseudo widgets: handles/grids/guides)
- Desktop Widget
There are multiple problems with this structure at the moment:
- Functionality is mixed up between the desktop, the desktop widget (and it's "View" base class), and the canvas.
- There is no easy way to change renderers.
- The code is overly complex.
Proposed structure:
- InkscapeWindow
- Menu bar
- Tool control bar(?)
- Status bar
- Palette
- InkscapePaned widget
- Dialog notebooks/toolbars (drag and drop)
- Canvas Grid Widget
- Rulers
- Scrollbars
- Buttons
- Canvas Items/Groups
- Canvas Renderer (only renders objects)
- Canvas Overlay (receives events)
The key proposal here is to separate out event handling into a Gtk::Overlay widget. The Canvas Renderer widget would then be solely responsible for rendering. Both the Canvas Renderer and Canvas Overlay would need to be aware of the positions of Canvas Items and Groups (the first for rendering, the second for determining where to send events).
An alternative that might better divide up functionality:
- InkscapeWindow
- ...
- ...
- Canvas Grid Widget
- Rulers
- Scrollbars
- Buttons
- Canvas Container (includes transform code)
- Canvas Items/Groups
- Canvas Renderer
- Canvas Overlay
- ...
Independent of this proposal is to move all canvas transform (zooming/scaling/translating) code into either the Canvas Grid or the Canvas Container widget as this code is tightly bound to the canvas and to keeping the rulers and scrollbars in sync. It does not belong higher up in the widget tree.
With the use of Gio::Actions, this proposal should result in a much simplified code structure and a more flexible Inkscape.