We need to store the current 'view' so that Expose callback from X11 can be handled effectively. This is the job of the Canvas.
A Canvas is a rectangle which contains:
- a background
- some canvases, each with location, size and depth
- some text objects, each with a string, a location, a depth, a font, and a colour
The objects in a canvas are listed in back-to-front order so they can simply be rendered one at a time.
We could use X subwindows for canvases, or we could manage sub-canvases all internally. I would prefer the latter - we'll see how that goes.
In the first instance, we simply redraw everything on any expose event. Later we might try to optimise a bit and only re-render the bits that are changed.
Operations on the Canvas involve changing any attribute of any object (location, font, colour, text), deleting objects, and adding new object. As each object has an explicit depth set by the application, position in the sort-order is determined using the depth. If two overlapping objects have the same depth, the result is undefined.
These objects are presented to Python as canvas.pane and canvas.text. canvas.canvas is a subtype of canvas.text which can be the root and must have an opaque background.
We also have canvas.font, canvas.colour. Here "font" actually means a particular face in a particular size. Possibly colour and font should be combined into the one object...
The Canvas widget needs to also mangage input from the X server.
