Re: [guppi-list] Re: Plot idl

[Havoc Pennington <rhpennin midway uchicago edu>]

On Wed, 16 Sep 1998, Dean Brettle wrote:
> 
> Regardless, I think plots will need to deal with strings for something
> like a bar graph of the populations of different cities.  You would need
> strings for the city names.
>

Ah, of course. I need to write something other than scatter plot to get an
idea of what will be needed.
 
>   // Return the values as a sequence of doubles coercing as necessary.
>   DoubleSeq get_as_double_seq(in unsigned long start_index, in unsigned
> count)
>     raises(OutOfRange,CoercionError);
>

If we're doing this, why not just:

interface Row {
 // title, whatever
};

interface DoubleRow : Row {
 // get values, set values.
};

and skip all the union annoyance? That seems nicer to me right now.
 
> It also sound like you are thinking of using a sequence of Axis, each
> with one set of values.  This will work, but it means that if you have
> many overlays on a simple 2-D plot, you have many Axis objects which are
> identical except for the values.  I think you are better off allowing
> multiple Values objects per Axis object.  

This is what I meant to say, but I wasn't thiking ahead far enough. It's
not enough in itself, because in addition to overlay you have arrays of
plots. So for each Axis you need a sequence of subobjects, each subobject
keeping a set of values overlaid on a particular plot in the array.  Whew.
Confusing.

> You could do this by storing a
> sequence of Values objects within each Axis object instead of just one. 
> I recommend against that as well however.  It confuses the model
> (Values) with the view (Axis). 

Excellent point, it will help out Guppi's internals too. I was just
futzing with this.


I played with the IDL some more and I have begun to question the goal of
the interface. Basically the problem is this: how much functionality to
export? One extreme is: you just stuff a table of data into Guppi, and all
manipulation of the plot happens in Guppi. So the interface consists of
do_scatterplot(in Table table); and not much else. 

At the other extreme, you can let the client set fonts, font sizes,
spacings, colors, etc.; every time you add a new feature to Guppi you
export it with CORBA. This is way harder to maintain and debug than the
minimalist version; on the other hand, it would let Gnumeric be smart
about certain things, for example preserving the spreadsheet formatting of
a title in the plot. It also encourages scripting. There are possible
performance issues; I don't know how problematic it would be. 

Where do people think the perfect balance is?

Havoc