Inkscape Canvas

From Inkscape Wiki
Revision as of 09:09, 12 June 2020 by Tavmjong (talk | contribs) (Created page with " 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. #...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This page is for discussions about how the Inkscape Canvas should be structured.

See also Future Architecture.

The key goals are:

  1. To allow for a modular Inkscape.
  2. To allow for multiple independent renderers (Cairo, OpenGl).
  3. 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)

There are multiple problems with this structure at the moment:

  1. Functionality is mixed up between the desktop, the desktop widget (and it's "View" base class), and the canvas.
  2. There is no easy way to change renderers.
  3. 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.