Re: terminal API: Intent of multiplot suspend/resume?

[Ethan M. <merritt@u.washington.edu>]

On Thursday 14 July 2005 12:30 pm, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> > On Thursday 14 July 2005 11:49 am, Hans-Bernhard Broeker wrote:
> 
> >>* Removing suspend()/resume() completely would be a Very Bad Idea[TM].
> 
> > Removing them would save about 400 bytes of permanent storage in
> > TERM_TABLE.  Other than that it's all cosmetic.
> 
> It would also render 5 more-or-less independent terminal drivers 
> unusable for interactive multi-plotting.  That's what would make it bad.

You misunderstood me.  I was proposing to replace the separate 
TERM_TABLE entries with sub-options to term->private() or whatever
this new API entry would be called.  So existing calls to 
term->suspend()  would become calls to term->private(SUSPEND).

> > The cause of my confusion was the implication in the existing 
> > documentation that these routines could be used to detect the
> > change between one multiplot plot and the next.  They cannot.
> 
> Yet they are.  See the X11, OS/2 PM, Windows, mac and aquaterm drivers.

???   The point is that I cannot use them for the purpose of detecting
such a change *in general*, because they are only called under certain
conditions.
 
> But if we do add a "term->next_multiplot()" call or similar, then yes, 
> these should probably be modified to move that functionality to the new 
> call.  

Exactly.  Except that it should be folded into a more generic API.

> For good measure, such a call should also carry the current  
> "interactive" state as an argument, so the driver can decide whether to 
> trigger a replot or not.

Terminal drivers can test for "if (interactive)" on their own.
They don't need to have it passed to them as a separate parameter.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195