31.03.2000

Well, we end with 2 basic objects:

SPDocument - the base of all nongraphical wizardry.

Although you can well do all things via repr tree, Document will have some

neat features:

Undo stack managing: start_undo_step, end_undo_step

Selection grabbing - we can select via reprs, which is otherwise impossible

NB! SPDocument is SPRepr ref holder NB!

SPDesktop - the base of all graphical wizardry

What follows, is outdated...

Document hierarchy

This is currently in active rewrite. Structure should be something like:

SPApp - main application thing, probably GnomeMDI in future

SPDesktop - one view to one document

SPDocument - SPItem tree rootmost element

SPItem tree refers to xml backbone (currently reprs) and Canvas trees.

Backbone does not know anything about other items/classes/objects. There

can be more than one canvas tree (desktop) associated with document.

There is (and should be more) event interconnection between different

objects.

Editing can be done to all three levels, but should end up with modifying

reprs. No other change will be saved.

1. Non-interactive modifications (for example changing object color)

These should be done directly to backbone. Probably I'll implement a separate

wrapper thing (sp-app-repr-interface.h or similar) to minimize the need

to include lot of headers for such modules. These will be also probably the

first interface to plugins.

Such modifications will instantly propagate to all items and views and will

be preserved when saving, duplicating & so on.

2. Interactive modifications to SPItems

These are a bit faster (no need of coding/decoding, allocing, freeing xml

attributes). Changes will display instantly to all views, but WILL NOT

propagate back to xml. The right way to use such things is:

When button pressed, grab mouse pointer

Do modifications to SPItem

When button released, write modifications to SPRepr

3. Interactive modifications to GnomeCanvasItems

These affect only the current display (desktop) and DO NOT propagate back

neither to SPItems, nor SPReprs. Use with same caution, as the class above.

Undo/Redo, when implemented, will be probably extracted from xml

There are several more things, like

SPSelection - a per desktop selection (selection.h)

Handful of canvas groups for grid, guidelines & so on (desktop.h)

Intermediate holders of currently modified data (all contexts)

SPNodepath (nodepath.h)

---------------------

Document == SPRoot

Provides convenience constructors

Selection { /* opaque */ }

Per desktop structure, pointing to selected items

Desktop {

Selection selection

Document document

}

macro ACTIVE_DESKTOP ;) gives current active desktop ;-)

There will be probably several macros to deduce affected desktop from

UI events (menus & so on)