From cca66b9ec4e494c1d919bff0f71a820d8afab1fa Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 20:24:48 +0200 Subject: Adding upstream version 1.2.2. Signed-off-by: Daniel Baumann --- doc/README.document | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 doc/README.document (limited to 'doc/README.document') 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) + -- cgit v1.2.3