Name Date Size

.. 2016-03-16 18:20:29 75

architecture.svg 2006-01-16 03:36:01 24.4 KiB

architecture.txt 2006-01-16 03:36:01 19.8 KiB

ChangeLog_archive.txt 2014-02-19 08:05:37 742.9 KiB

class-hierarchy.dia 2006-01-16 03:36:01 6.5 KiB

coordinates.txt 2006-01-16 03:36:01 1.4 KiB

extension_system.txt 2016-03-16 18:20:29 18.3 KiB

extension_system.xml 2015-03-08 17:10:20 22 KiB

HACKING.de.txt 2014-12-25 21:31:09 3.3 KiB

HACKING.fr.txt 2014-12-25 21:31:09 4 KiB

HACKING.it.txt 2014-12-25 21:31:09 3.6 KiB

HACKING.pt_BR.txt 2014-12-25 21:31:09 3.7 KiB

HACKING.txt 2014-12-25 21:31:09 3.4 KiB

inkscape-uml.dia 2006-01-16 03:36:01 7.6 KiB

keys.be.html 2014-12-07 08:32:59 356.6 KiB

keys.css 2011-07-25 21:29:40 3.9 KiB

keys.de.html 2015-09-10 08:58:04 323.2 KiB

keys.el.html 2014-12-07 08:32:59 364.6 KiB

keys.en.html 2014-12-07 08:32:59 305.6 KiB

keys.fr.html 2014-12-07 08:32:59 323 KiB

keys.ja.html 2014-12-07 08:32:59 329.5 KiB

keys.README 2010-10-15 15:17:34 192

keys.zh_TW.html 2014-12-07 08:32:59 307.8 KiB

LOGGING.txt 2013-09-29 06:01:04 662

Makefile.am 2014-12-07 08:32:59 361

markers_design.txt 2007-02-18 03:48:41 5.5 KiB

NewAppArchitecture 2006-05-07 06:21:16 16

nr-filter-interface.txt 2006-07-04 16:05:32 8.7 KiB

PDF Feature Matrix.ods 2006-10-29 01:38:19 11.2 KiB

PDF Feature Matrix.svg 2006-11-25 15:10:33 34.8 KiB

README.document 2006-01-16 03:36:01 2.7 KiB

refcounting.txt 2006-04-29 20:46:49 5.9 KiB

spsvgview.txt 2006-01-16 03:36:01 694

keys.README

The Keyboard and mouse reference HTML files are now extracted from the
inkscape-doc project.
See http://bazaar.launchpad.net/~inkscape.dev/inkscape-docs/trunk/files/head%3A/keys/ for details.

README.document

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)