Re: [Ocaml-gnuplot-devel] plotitems, tags and global style setting
Status: Beta
Brought to you by:
chris_77
From: Christophe T. <chr...@us...> - 2004-08-11 14:04:00
|
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 |