Re: [guppi-list] Re: Plot idl

[Dean Brettle <dean brettle com>]

Havoc Pennington wrote:
[snip]
> >   // 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.

That could work.  The only disadvantage is that if the same Row is being
used in two different Plots and one requires doubles and the other
requires strings, the Row provider must create two objects (1 DoubleRow,
1 StringRow) which are interfaces to the same real object.  In my
scheme, the provider would just create a Row and implement the methods
that make sense for the data.  If, for example, the data doesn't make
sense as doubles, the doubles methods would just throw CoercionError. 
Also, you don't really need the union anymore or the get_as_values() and
set_as_values() methods anymore.  Callers would always use the other
methods.

BTW, I'm assuming that Row above is similar to Values from before.  I
definitely like the name Row better than Values because it is singular,
but you might want something which is less, err, directional. :)  How
about something like Vector?  I don't know...just a thought.

[snip]

> 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?

I recommend exporting as little as possible to start while
simultaneously ensuring that future additions can remain compatible.  To
that end, I think you need something like a Values/Row/Vector interface,
a generic Plot interface, and then derived interfaces for each Plot type
you provide.  I have attached one possibility below.  I've changed
Values/Row to Vector and added a VectorFactory interface which would be
implemented by guppi for callers that do not provide their own Vectors.

BTW, have you been following my discussion with Paolo on the gnumeric
list or are you only subscribed to guppi-list?

--Dean


interface Vector {
  attribute string name;
  readonly attribute unsigned long size;

  typedef sequence<double> DoubleSeq;

  // 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);

  // Set the values from a sequence of doubles, coercing as necessary.
  void set_from_double_seq(in unsigned long start_index,
                           in DoubleSeq seq)
    raises(OutOfRange,CoercionError);

  typedef sequence<int> IntSeq;

  // Return the values as a sequence of ints, coercing as necessary.
  IntSeq get_as_int_seq(in unsigned long start_index, 
                        in unsigned count)
    raises(OutOfRange,CoercionError);

  // Set the values from a sequence of ints, coercing as necessary.
  void set_from_int_seq(in unsigned long start_index, 
                        in IntSeq seq)
    raises(OutOfRange,CoercionError);

  typedef sequence<string> StringSeq;

  // Return the values as a sequence of strings, coercing as necessary.
  StringSeq get_as_string_seq(in unsigned long start_index, 
                              in unsigned count)
    raises(OutOfRange,CoercionError);

  // Set the values from a sequence of string coercing as necessary.
  void set_from_string_seq(in unsigned long start_index,
                           in StringSeq seq)
    raises(OutOfRange,CoercionError);
}

interface VectorFactory {
  // Creates an empty Vector for use in a Plot
  Vector create_vector();

  // Destroys a Vector created by this factory
  void destroy_vector(in Vector v);
}

// Base class; all plots can do this
interface Plot {
  //  display on screen in a window.
  //  The window may offer a way to edit the plot.
  void display();
  
  // I ditched the get_postscript() for the moment.
  // It can be added when it is available. --DWB

  // I also ditched the Table.  If the plot program allows for
  // editing of the values, I think they should be changed through
  // the Vector interface, on a plot-by-plot basis. --DWB

  // The title of the plot - user can 
  //  probably change this with the editor.
  attribute string title;

  // Eventually we want a way to get an embeddable object,
  //  to embed in the spreadsheet or whatever. 
  // Then display() is just a shortcut for obtaining this object
  //  and sticking it in a standalone window.
};

interface TwoDPlot : Plot {
  // No Axes initially --DWB

  // use x_values->get_as_double_seq()
  attribute Values x_values;

  // use y_values->get_as_double_seq()
  attribute Values y_values;

  // error bars and data point labels and styles
  // can easily be added later --DWB
}