77 lines
2.7 KiB
Text
77 lines
2.7 KiB
Text
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)
|
|
|