Object Graphics Issues

Bill Denney <[email protected]> Sun, 7 May 2006 23:08:17 -0400 (EDT)
Newsgroups gmane.comp.gnu.octave.graphics
Message-ID <[email protected]>
So, I've been coding a decent bit on the object graphics front-end, and 
I've thought of a few more issues:

We have a good set of primitives, but we don't really have a good set of 
non-primitive graphing functions.  For example, we have all the 
primitives needed to make a bar plot with error bars, but once it's 
created, we've lost information because we don't have a mechanism to keep 
that information after the initial creation.  I think that a good, 
extensible method for doing this would be something like this:

Any compound plot type (such as a bar plot) would be a specific 
implementation of the group object.  We could add three fields to the 
group object:

GroupType- would indicate what type of plot it was (just a name)
ModificationCallback- would be called with the parameter of the handle to 
the current object upon any modification of that group
Extra- would hold all data needed by the ModificationCallback function to 
create the graph (things like xdata, ydata, xdata, color, etc)

This enables the creation of arbitrary graphics types (either built into 
octave or user created) easily.  It also means that backends wouldn't 
necessarily have to understand all the types of graphs, just the 
primitives, because the ModificationCallback function would create the 
primitives within the group.  For groups used strictly for grouping, the 
fields could be empty.

A secondary issue to me is a question internal to the structural 
representation of the objects.  What advantages are there to using a 
vector of structs instead of a vector of cells as the basic object holder? 
The reason I ask is that an advantage that I see to using a vector of 
cells (each containing a struct) would allow easy testing of the 
applicability of a field-- we could just see if the field already exists 
to see if it is possible to put data into it.  Otherwise, (as I see it) 
each type would need a specific function to see if a fieldname was 
available.

The final issue is that I think that not just the group type should have 
the "Extra" field because it allows flexibility to the future programmers 
without requiring extra primitives to be created for each specific 
graphics type.

Bill

-- 
"At the beginning and at the end of love, the two lovers are embarrassed
to find themselves alone."
   -- La Bruyere