Re: Adding graphic capabilities to Gnumeric

[Havoc Pennington <rhpennin midway uchicago edu>]

On Thu, 8 Oct 1998, Miguel de Icaza wrote:
> 
>      So, my goal is to be able to use Guppi for the emebedded graphic
> inside the graphic region, but I dont think Guppi is quite ready for
> this setup.  So we would have two modes of operation: Graphic modes
> that are fully Gnumeric aware (by using the gnome canvas as their
> engine) and the external plot-only widgets.
> 

[ this email got really long; sorry. skim the boring parts... ]

I don't think we need two modes; Guppi should be able to do this too. 
We just need to talk about how to do it.

The plot plugins for Guppi basically do this interface (not in C, a little
more complex, but you get the idea): 

GtkWidget* get_plot_widget(PlotContext* pc);
const char* get_menu_name();

The PlotContext has the list of available data to plot and can eventually
be extended to have whatever we care about. So basically you get a
collection of data and your widget has to plot the data and optionally
edit it.

Complicating this, the plugins have to track the state of the data via
signals. So if new data becomes available in the PlotContext they have to
do the right thing; if the data changes (e.g. someone takes the log of it
or the data is edited via a different plot or Gnumeric) the plot has to
respond. This means that the data manipulation engine and the plot GUI can
be separate.

A second eventual complication is load/save; the plot plugins will
eventually need to load and save their state. Guppi or Gnumeric will be
able to save the data, so the plot plugins will just keep a reference to
it.

Right now there is also a get_editor_widget() but I would like to move
away from that, and have all the editing happen by clicking on the plot in
various ways. This is how embedded stuff works on Windows if I recall
correctly, and it's just a nicer interface. Double-clicking an axis might
bring up a dialog to change parts of the axis you can't change directly
with click-and-drag.

Anyway, as you can see there's nothing to prevent a GnomeCanvas in any of
that.

<Begin long historical tangent about why the scatterplot is how it is>

There's no reason Guppi or its plugins can't use GnomeCanvas. I almost did
use it this time around, but I had things set up with a separate widget
for each axis and plot; and widget support on the canvas was/is pretty
broken (I tried it for a while). Most of the changes in this version set
up the underlying data representation and plugin stuff, and my next step
is to fix the interface and plot display. 

I no longer want to use separate widgets, so that isn't a barrier to using
the canvas.  I just need to do the rewrite. However, it isn't as easy as
you might expect. If the scatterplot markers were canvas items, it would
be easy to do click-and-drag on them; but for large numbers of markers
that is completely impractical. (See how long it takes to create several
thousand GtkObjects sometime.) So basically I need a canvas item which
represents *all* the plotted scatter points and handles which one is being
selected. I need to write that item, etc. It just isn't done yet. 

This doesn't mean tossing out all the Guppi code because 90% of the plot
stuff just draws to a drawable, and canvas items also just draw to a
drawable, IIRC. So the Gtk--Plot routines will all work with a canvas, if
we create the appropriate canvas items which is easy in C++.  Also, all
the parts of the scatterplot editor widget are separate widgets and the
GUI is pretty separate from the underlying objects. So all those things
can be reused in popup dialogs or whatever makes sense. 

<end long tangent>

Anyway, since Guppi uses signals to track changing data, and there can be
any number of "views" on a given piece of data (multiple plot types, or
whatever), there's nothing in Guppi to prevent changing data by clicking
on the plot. The only thing to work out is how to communicate data back
and forth to Gnumeric without sending arrays all over the network every
time a single data point is changed.

I don't want you to wait for me to finish re-hacking the scatterplot
before starting to work with Gnumeric. Since I code at 1/10 the speed of
Miguel I don't want to put the brakes on things. :-)

The following would help move stuff along:

 - Someone could write the code to export Guppi's ColumnDoc (should be
   renamed to ScalarData) and CategoricalData classes to an IDL Vector, 
   as seen in gnome-plot.idl.
   The CORBA stuff can be done in C, as long as the C++ compiler
   builds it. I already have a build environment for a little 
   test program which does this in src/plot-server/, if someone wants 
   to write the test program. This would create new ColumnDoc and
   CategoricalData objects, and a vector factory, and let a client 
   ask for and manipulate vector objects.  

   I'm thinking Gnumeric will ask for a Vector object from Guppi, which
   will be a ColumnDoc or CategoricalData object. Then it will stuff its
   data into that, and request a certain kind of plot, which Guppi
   provides and Gnumeric embeds. 

   This requires Gnumeric to monitor the CORBA data vector and update its
   sheet display. Alternatively, Guppi could ask Gnumeric for a vector,
   and Guppi could monitor the CORBA object; however, since plotting
   usually involves more intensive access than displaying, I'm not 
   sure that makes sense. I don't know how the monitoring will work;
   some kind of events?

 - Someone could start on some kinds of plot other than the scatter 
   plot, like pie or bar chart. The low-level stuff can be in C, but
   at some point you have to switch to C++ in order to track the 
   signals from Guppi's data vector objects. Since a bar or pie chart
   is simpler than a scatterplot, you could probably get it going 
   pretty quickly and use it as a testbed for the CORBA stuff.

 - It would be helpful to have a description of how the Excel interface
   works. In general, what do all the plots do the same way? What does 
   double-clicking with each button do? Does the interface work without
   a spreadsheet present? Does Excel have a scatterplot?

 - Loading and saving for Guppi and the plot plugins. The plugins, Guppi,
   and Gnumeric will all need to interact somehow to load/save compound
   documents.

 - GnomeCanvas needs gnome-print functionality, and better widget support.
   I'd also like to see "snapshot" functionality, where it draws to 
   a pixmap and the pixmap can be saved/scaled via Imlib.

So tell me what you want to do next. I would like to spend a lot of time
on cleanup; rewriting the scatterplot properly, fixing the transform
plugins, chasing segfaults, etc., so that Guppi works OK on its own.
But someone else could go ahead and start on CORBA support and other
kinds of plugin. The plugins are not related to each other in any strong
way (though libguppi provides reusable components they can all take 
advantage of, and they all share the same data vectors).

If it's helpful I can explain any part of the Guppi code that's confusing.
Hopefully it's mostly clear.

BTW, I'll be at Atlanta Linux Showcase in a couple weeks, it might help to
go over some of this in person.

Havoc