[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

:zz: Chains of decorations?? Christmas is coming!

Wow, Mark-Jason--

I don't fully follow it.  But I like it.  T

At 01:31 PM 11/15/98 -0500, you wrote:
>> 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.
Theodor Holm Nelson, Visiting Professor of Environmental Information
 Keio University, Shonan Fujisawa Campus, Fujisawa, Japan
 Home Fax from USA: 011-81-466-46-7368  (If in Japan, 0466-46-7368)
Professorial home page http://www.sfc.keio.ac.jp/~ted/ 
Permanent: Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
 Tel. 415/ 331-4422, fax 415/332-0136  
PERMANENT E-MAIL: ted@xxxxxxxxxx
Quotation of the day, 98.11.12:
"Everything is just like everything else.  And sometimes even more so."