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