Re: (techy) window_draw and key_pressed

[Mark-Jason Dominus <mjd@xxxxxxxxxx>]

> I'm prodding at source again and I don't quite see why window_draw
> needs to know whether there was a key pressed.

Me neither.  Seems like bad design.

> I also can't figure out how to cope with that special-case while
> decoupling  the functions from IO.

Well, I haven't thought about it too much, but maybe the special case
isn't important.  I mean, suppose the program redraws the border and
the status bar more often than it needs to?  Then so what?  That
doesn't take long.  The curses package will notice that it hasn't
really changed and won't generate any extra screen I/O in that case.

> Perhaps window_draw needs to know what happened so it can figure out
> what to draw?  eg window_draw("cursor moved"), window_draw("cell
> marked") or something?  That seems inelegant to me.
> 
> Suggestions?

The `elegant' method is to use a `decoration' design.  Suppose you
have a class of objects that represent things that can be drawn on the
screen; let's call this class `Drawable'.  Different sorts of
drawables will be subclasses of Drawable.  For example, Window is a
subclass of Drawable.

A special kind of Drawable is `Decoration'.  A Decoration is a kind of
drawable thing that adds some features or decorations to another
Drawable.  It has a reference to the Drawable that it decorates.  For
example, there's a Window object for the data window, without border,
cursor, or the cell number in the lower right.  Then there's a
Decoration object which adds the border, and it has a reference to the
window; there's another Decoration object which adds the cell number,
and it has a reference to the border decoration object.

All Drawables, including Decorations, support a `draw' method, which
tells the object to make the appropriate curses calls to render the
object on the screen.  Decorations also have some special methods that
control the decorations themselves.  For example, the cell-number
decoaration will have a method for changing the number that appears in
the corner of the window.  What makes a Decoration special is that
when it gets a `draw' request, it forwards it to its dependent
drawable first, to redraw the window that it decorates; then it adds
its own decorations.

You can use the Decoration object as if it were the original window.
You can chain together a whole bunch of decorations, each one
dependent on the next one.  Each will add a new decoration to the
stack of decorations below it.  But each piece of the program only
needs to know about the Decorations it's planning to change.  If some
part of zigzag only needs to change the cell number, it only needs to
talk to the cell-number Decoration, not to the main window.

This was pretty abbreviated, and I don't know if it'll make any sense,
but maybe it'll get you started thinking about it.