-*- outline -*-
 Zowie TODO
--------------------------------------------------

*Features

- #1 thing to solve: How is the thumbnail /supposed/ to work?  (Where
does it zoom in on, etc.)

- Put together a set of standard controllers -- see how Squeak factors
them.

- Write models: bounds-model; document-model; pluggable-model (give it
the accessors to use -- see Squeak).

- Finish the damage model.  Can be simple (full screen update in the
event dispatching thread), then damage rects that can be coalesced.  I
like Pad++'s damage model -- it is a nice separation which lets us
(try to) maintain a frame-rate independently of input events.  Check
out Pad++, Jazz, Squeak.
  - Damage will need to coalesce or just compare rectangles -- what
  happens in the case of rotated rectangles (can still do it but need
  the other two corners ..).  Could just test the zorph transform for
  rotated-ness (should be cheap) and have a special case for that.

- Protocol for sending input events on to sub-zorphs/viewed things
  - May also involve some notion of focus and selection
  - Might it be useful to introduce higher-level abstractions or
  syntax for controllers?  Bauhaus/Dylan has macros for this,
  allegedly.  It's worth thinking about a useful DSL.

- A text zorph

- Fill/stroke styling.

- Abstractions for interfacing with the outside world -- the frame and
so on.

- Primitives for:
  - Zorph menus (halos, pie menus)
  - UI feedback -- messages, selection marquees (or otherwise),
  navigation markers (for the center of zooming for example) and
  waypoints.

*Refactoring

- Factor out zorph mixins -- view, children, bounds etc.  Can combine this
with zowie node mixins.

- Move the fill/stroke styling into a model of some kind.

- Traits-y-ness: sort out conceptually the hierarchy, and make the
mixins more like traits -- rather than relying on call-next-method,
provide distinct functions which can be composed (in other traits
even).

Other candidates for traits: alpha; group; have a look in the traits
files, maybe draw it out on paper.  Fill-style and stroke-style have
to be separate (required by filled, stroked, filled-and-stroked?).

- Make the damage protocol into a set of paired mixins/traits (or just
make a partner for <zw.viewed>?)

- Consider separating bounds from clipping rectangle.  These should
really be distinct.  How are (explicit) bounds, spatial extents, and
clipping related?  These are all mixin candidates.

- Have a look at the gesture abstraction in zowie/piccolo -- is it
useful?  Could be part of the standard controller library.

*Questions

- Debug redrawing zorphs -- do I need the whole render protocol or is
paint enough?  I think when I move transforms into zorphs I may need
to do this or something like it, for the same reason I do it for
nodes.  What does Squeak do?

- How can I avoid recaclulating things like bounds, rectangle co-ords,
as I progress up the call-next-method chain?  Caching is one way;
perhaps use mixins/traits rather than direct inheritance.

- Try using glitz with cairo -- hand SDL's surface to glitz, and
glitz's drawable to cairo.  Glitz may have a slightly troublesome API
-- not sure yet how to get hold of a drawable/surface.

*Bugs and periphera

- Make sure zorphs report reasonable bounds
  - what happens to rotated things?  Have to square-off their bounds,
perhaps when coalescing.  Maybe have more than one implementation of
rectangle, and resort to the other when we have a rotation, and
convert back when we need to (like when reporting bounds)
  - text zorph may need to use cairo-text-extents, which needs some
thought.

- Rendering slows down somewhat when you zoom in lots; is it because
  1. the clipping is expensive;
  2. rasterizing large things is expensive, even when clipped;
  3. precision at large zoom levels is problematic; or,
  4. some other thing?
  There's some suggestions
  (http://lists.freedesktop.org/pipermail/cairo/2004-December/002325.html)
  that clipping (even default clipping) can be expensive, allocating
  large alpha masks.  I wonder if it's this, or some related problem
  with allocating large surfaces when compositing.  Aligning along
  pixel boundaries may help (again, see the post).
  
  I've fixed this to some degree by explicitly neglecting to draw
  things outside the camera bounds; now I believe only things massive
  *and* in-frame will slow it down.  It might /also/ pay to round the
  transformed clipping rect to pixel boundaries.