DiaCanvas using GnomeCanvas
-------------------------

One attractive option is to use GnomeCanvas for rendering while
we keep the information in a separate object.
A few points should be taken into account:
1. GnomeCanvas has itself an object hierarchy. This means that most actions
   should be forwarded to the data item (DiaCanvasItem) and persize feedback
   should be given to the GnomeCanvasItem deriviate (DiaCanvasViewItem).
   These things should be done at the lowest level possible and should not
   be noted by the object programmer. In fact: people creating new objects
   should only be aware of DiaCanvasItem and the rest should all happen under
   the hood.
2. Some actions (like rotating an object) happen without the knowledge of the
   DiaCanvasItem. Of course it can read its affine transformation matrix,
   but the shapes that are created and the handles that are attached to the
   DiaCanvasItem do not have to be redrawn. The DiaCanvasViews take care of
   this.

Advantage:
-  GnomeCanvas is a stable fundament by now.
-  We don't have to handle rendering.
-  The design doesn't differ much wrt the original DiaCanvas design.

Implementation
------------
The Canvas used in DIA has a few special features:

- Handles are always drawn on top of the object shapes.
This is a very handy feature: one can grab the handle of an object (and see
it) even if there's some other object on top.
To implement this we need a special layer: DiaHandleLayer. This object should
be the topmost layer of the canvas. All this object does is drawing all
handles inside a drawing rectangle and figuring out if an event (key press,
key release and otion) occurs on top of a handle. If there's a handle, the
DiaHandleLayer takes the canvas' grab() and handles the events depending on
the options of the handle. A handle notifies its owner (a DiaCanvasItem) that
it has moved and the DiaCanvasItem can take proper action (like rescale).
- A grid is used. This is like the DiaHandleLayer, only the grid is drawn
on the bottom.

Updating
------

Just like GnomeCanvasItems, DiaCanvasItems use both a render and an update
phase. The render phase is totall taken care of by the GnomeCanvas (which
we inherit to DiaCanvasView). The DiaCanvasView needs some extra information
that is gathered during the update phase.

Updateing goes as follows (UML like sequence diagram):

		  DiaCanvasItem		DiaCanvasViewItem	    main loop
			|			|			|
 -- request_update() -->|			|			|
			|-- request_update() -->|			|
(schedule an update)	|			|- schedule update() -->|
			|			|			|
			| { if (NEED_UPDATE) }	|<-- update() ----------|
(update DiaCanvasItem	|<-- update() ----------|			|
 if it want to)		|			|			|

DiaCanvasItems will probably create some DiaShapes that have to be drawn. The
DiaShapes are transformed and a renderer friendly form is stored next to the
DiaShape (in a DiaShapeViewInfo structure). 

Events
----
Events are directly forwarded from the DiaCanvasViewItem to the DiaCanvasItem.

Handles
-----
Like DIA's objects, the new canvas sports handles. Handles are defines by the
object and the are quite passive: All events are handled by the DiaHandleLayer
that is used to draw the handles on top of the objects. The DiaHandleLayer
asks the DiaCanvasItem if the canvas' movements is justified by calling
handle_motion(). This might seem not very flexible, but at least it ensured
consistent behaviour of tha handles, something the user appreciates.

