Re: smooth shading & terminal specialities

[<br...@ph...>]

Daniel J Sebald wrote:

> I'm not completely following, and I think I'm still wondering about the 
> terminal function mechanism.  Perhaps I'm used to thinking of C++ where 
> one can override the function of a class and in some cases if base 
> object in question doesn't have an overriding function, the function 
> falls back to the base function.

That's quite exactly what term.c does.  But being written in C, it has 
to be done manually, instead of some C++ runtime magic doing it for us.
term/README should be clear enough, really, but here's how it works:

struct TERMENTRY is an interface (an pure abstract base class, in C++ 
jargon).  An adapter class (providing fall-back implementations for 
several of TERMENTRY's methods) is in term.c.  Viz. do_arrow(), 
do_point()...  Each terminal driver is a derived class of this adapter. 
  It will implement some methods, but doesn't have to implement all. 
Those it doesn't implement are marked by zeroes in the TERM_ENTRY part 
of the .trm file.  The "class loader" in term.c replaces those dummies 
by the adapter classes implementations.


> 
> The idea would be that for terminals which don't support term->image() 
> there would be a base version of image_rhombus() (or some such thing) 
> that draws an image using rhombuses and effectively acts the way pm3d 
> currently does.

Feel free to write a do_image(), put it in term.c, and add it do the 
adapter class by updating the "class loader".