"SfR Fresh" - the SfR Freeware/Shareware Archive

Member "inkscape-0.46/doc/README.document" of archive inkscape-0.46.zip:

As a special service "SfR Fresh" has tried to format the requested source page into HTML format using source code syntax highlighting with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. That can be also achieved for any archive member file by clicking within an archive contents listing on the first character of the file(path) respectively on the according byte size field. 
    1 31.03.2000
    2 
    3 Well, we end with 2 basic objects:
    4 
    5 SPDocument - the base of all nongraphical wizardry.
    6 Although you can well do all things via repr tree, Document will have some
    7 neat features:
    8 Undo stack managing: start_undo_step, end_undo_step
    9 Selection grabbing - we can select via reprs, which is otherwise impossible
   10 NB! SPDocument is SPRepr ref holder NB!
   11 
   12 SPDesktop - the base of all graphical wizardry
   13 
   14 What follows, is outdated...
   15 
   16 Document hierarchy
   17 
   18 This is currently in active rewrite. Structure should be something like:
   19 
   20 SPApp - main application thing, probably GnomeMDI in future
   21 SPDesktop - one view to one document
   22 SPDocument - SPItem tree rootmost element
   23 
   24 SPItem tree refers to xml backbone (currently reprs) and Canvas trees.
   25 Backbone does not know anything about other items/classes/objects. There
   26 can be more than one canvas tree (desktop) associated with document.
   27 
   28 There is (and should be more) event interconnection between different
   29 objects.
   30 
   31 Editing can be done to all three levels, but should end up with modifying
   32 reprs. No other change will be saved.
   33 1. Non-interactive modifications (for example changing object color)
   34 These should be done directly to backbone. Probably I'll implement a separate
   35 wrapper thing (sp-app-repr-interface.h or similar) to minimize the need
   36 to include lot of headers for such modules. These will be also probably the
   37 first interface to plugins.
   38 Such modifications will instantly propagate to all items and views and will
   39 be preserved when saving, duplicating & so on.
   40 
   41 2. Interactive modifications to SPItems
   42 These are a bit faster (no need of coding/decoding, allocing, freeing xml
   43 attributes). Changes will display instantly to all views, but WILL NOT
   44 propagate back to xml. The right way to use such things is:
   45 When button pressed, grab mouse pointer
   46 Do modifications to SPItem
   47 When button released, write modifications to SPRepr
   48 
   49 3. Interactive modifications to GnomeCanvasItems
   50 These affect only the current display (desktop) and DO NOT propagate back
   51 neither to SPItems, nor SPReprs. Use with same caution, as the class above.
   52 
   53 Undo/Redo, when implemented, will be probably extracted from xml
   54 
   55 There are several more things, like
   56 SPSelection - a per desktop selection (selection.h)
   57 Handful of canvas groups for grid, guidelines & so on (desktop.h)
   58 Intermediate holders of currently modified data (all contexts)
   59 SPNodepath (nodepath.h)
   60 
   61 ---------------------
   62 
   63 Document == SPRoot
   64 Provides convenience constructors
   65 
   66 Selection { /* opaque */ }
   67 Per desktop structure, pointing to selected items
   68 
   69 Desktop {
   70     Selection selection
   71     Document document
   72 }
   73 
   74 macro ACTIVE_DESKTOP ;) gives current active desktop ;-)
   75 There will be probably several macros to deduce affected desktop from
   76 UI events (menus & so on)
   77