If you are interested in hacking sodipodi source, you are welcome. But be
cautious, as every single thing in structure/API may change yet. If you ever
have a good idea, how some subsystem should work, let me too know.

Some things that should be done (in random order):
- printing from command line, without display (worked, but is broken now)
- bonobo support (Skeleton is present, needs more flesh)
- plugin support
- good and clean API for dealing with selection changes (there is SODIPODI
  object - we need similar signalling for desktops, documents)
- gradient fills
- 'fast_art' rendering of svp-s (vpaths?) (without antialiasing)
- exporting bitmaps from command line
- all fancy filling types (fractals & so on)
- import and export filters
- port reprs to real XML (libxml, gdome)

Please consult with separate HACKING files in subdirs. Some modules
are only placeholders for something better and standardized (repr et al.)

You are always welcome to correct my spelling (except in variable names,
of course ;-)).

As of translating, be first sure, that the english phrases are correct
and meaningful (if they are not, somebody will replace these with better
ones)

This code should be quite modular and will become even more. Consult
doc/architecture.txt for more info, here is only rough blueprint:


1. reprs & cousins
SPRepr, SPCSSAttr ...
These are temporary wrappers around xml backbone. As soon as gdome is
usable for such tasks I'll replace these with DOM.
Currently reprs (Representation Objects) hold all item attributes. Object
tree is also constructed of reprs. They emit signals (to be exact - call
functions), if modified, deleted etc. Most editing should be done directly
to repr attributes.

2. Items

These are typed backbone of everything under the Sun. They know both about
reprs and canvas things, update itself (at least they should) if reprs change
and update canvas items, if they themselves change.

3. Graphics layout
desktop.c, drawing.c

Canvas root
Acetate, Desktop
Grid, Guides, Drawarea, Sketch, Controls

Acetate is borrowed from gill - it is basically infinite empty item, which
serves as mouse target

grid & guides groups
drawing - this is most interesting
sketch - simply a group I created for temporary items
controls - group which holds resizing buttons, rubberband etc.

Primary coordinate system for all items is desktop. This is mirrored
vertically to produce postscript coordinates. I.e. desktop unit = 1/72 in.
While reading svg, the drawing group will be mirrored once more, to produce
svg coords (y grows downwards)

The desktop will probably be broken into hierarchical trees of things like:
Desktop
    EditableDesktop
    PreviewDesktop
    BonoboContainer
& so on.

4. Selection
This is per desktop object, that keep track, which items are currently
selected. It is capable of emitting "changed" signal (probably in future
"attrmodified" too), to notice all interested parties about selection
changes (fill & stroke dialogs for example use this method)

5. Context
This object (hierarchy) defines, how mouse events on desktop are interpreted.
Every desktop has its own context (select, node, rect & so on)


Lauris Kaplinski
<lauris@helixcode.com>

