Re: [Ocaml-gnuplot-devel] plotitems, tags and global style setting

[Christophe T. <chr...@us...>]

Hi Viktor,

On Tue, 10 Aug 2004, Viktor Tron <v....@ed...> wrote:
> 
> ON LEVELS OF PLOTITEMS
> I think liberating plot-items from style is a good idea [...]  When
> you associate a plot-item with a viewport and a style, then you
> create another object

I do not really like that idea because it requires an additional step
to be able to plot something.  IMO, if one wants to re-plot the same
data, it is likely to be with the same visual characteristics
(e.g. for a zoom or to compare it with other plots).  It as also good
practice for the one who will interpret the plots because it creates
visual unity.

> 1. we need a level for the manupulation of plotitems for user's
> convenience and for erasure and redraw, replot on a different display.

With plotitems deprived of visual characteristics (e.g. linewidth), we
cannot erase them properly.  So either one has to provide again the
original plotting parameters for erasing (not nice) or to operate at
the level of "decorated plots" (but then what are the "raw plotitems"
good for?).

> 2. We need a way to be able to reuse the same data in different
> plots in different viewports without having to recalculate it.

Like I mentioned a [clone] function would be provided to redecorate a
plot.  I envisioned the possibility that plotitems (here decorated)
could be mutable or not to end up with the conclusion that it is
better they are immutable.  So:

> viewport has to remember the correct style (and linewidth) in order
> to be able to properly erase a plot

becomes a non issue.

> (b) sharing the data-content (which is equivalent to my solution).

Data would obviously be shared (otherwise this discussion does not
make sense).  Sure, this is equivalent to your solution but without
the overhead for the user of the library.  I do not want that
flexibility get in the way of getting simple plots done quickly.

> STYLE
> If you accept that style params like lines/points, width and color
> should be simultaneouly specified/absent on a particular level, then
> it follows that in the second case global setting of pen may not be
> a good idea.

???

> This is because plotitems are in principle handle-independent [...]
> so it would be strange to associate them with a handle only in order
> to know which pen to use to color them.

The [plotitem] type will be independent of [handle].  You are right
though that in order to create a "decorated" [plotitem], a handle will
need to be provided for styles.  Giving the decorations through
optional arguments does not appeal much to me (at present, 6 optional
arguments would be needed for pen, pen_width, point, point_width,
font, font_size).  Needing to provide these arguments again and again
(and also to pass them to functions) seems unpleasant to me.  An
intermediate solution would be to create a [decorations] (independent
of the [handle]) type that would be passed around.  But maybe this is
a bit overkill...

> ON TAGS
> On your other point about tags vs. just list of styled items given to
> the display functions, I don't understand if there is much difference.

There is not.  See below for a more detailed account.

> a) If we want to be able to redraw viewports automatically (a la the
> Managed tag) we can't get away without remembering the styled plots
> we displayed.

[Managed] may disappear.  More precisely, if a user deletes plots, he
has to care whether other plots may be damaged.  However, when e.g. in
autoscale mode we still may need full redraw so in this case we indeed
need to remember.

In order to re-plot we need a (mutable) structure that allows

* [iter]: iteration in the order plots where added;
* [snoc]: adding one more plot at the end;
* [remove]: deleting a given plot (when hiding, may be in the middle);
* [clear]: deleting all the plots (because e.g. of a new page).

Of course, if you explain that it is convenient for animations to have
a [Managed] state, that can be introduced too.  There is one
fundamental difference though: before tags were integers which means
we had to keep all plots for the viewport (even hidden) for fear they
would be re-plotted.  Now, only visible plots will be hold.  If the
user wants to re-plot a previously hidden tag, the tag itself (of type
[plotitem]) will hold the (shared) data.  If the tag becomes
inaccessible (and no other plot/tag uses the same data), the plot data
will be deleted.

> But if plotitems can be sequences of atomic plots, this is
> equivalent to having tags. Is it not?

Exactly.  Like you said, the user can do that easily with lists.  But
since we need anyway to have a module with the above functions, it may
be convenient to expose them for the user.  An additional benefit is
that groups of plots created with these functions would themselves be
of type [plotitem] thus allowing easy group manipulations.  Functions
like [show] would still take a list of plotitems because it is heavy
to group plots in such a way if one does not need to manipulate the
group later.

ChriS