Adding upstream version 1.2.2.upstream/1.2.2upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 77 insertions, 0 deletions

diff --git a/doc/README.document b/doc/README.document
new file mode 100644
index 0000000..e5f958c
--- /dev/null
+++ b/doc/README.document
@@ -0,0 +1,77 @@
+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)
+