From graphics-request at octave dot org Sat Dec 18 15:48:54 2004
Subject: Re: Octave GUI API: Proposal.
From: N Smethurst <nick dot smethurst at free dot fr>
To: graphics at octave dot org
Date: Sat, 18 Dec 2004 22:47:33 +0100

Hi Shai

> what you propose if I understand correctly is to implement this API as
> core octave type. To be concrete lets say there will be a "line" octave
> type. This type would implement the set and get functions as callbacks
> to some plugin.
> 1. Will the octave type contain all information as to the names and
> types of the "line" properties -- i.e. will it know there should be a
> "linestyle" property which can take one of the following values
> {"none",":","--" ....}?

What you describe is pretty much what I am interested in doing.

I will try and address your comments:

> 1.a If this data is in the octave type, will it support all Matlab(TM)
> properties from the beginning, or would I have to modify octave source
> each time my plugin would add support for some previously unsupported
> MATLAB(TM)new property?

Probably not in the Octave source, but definitely yes in the external graphics 
application.

However, how many new matlab properties have been created in the last five 
years? I see very little in the current specification that was not there half 
a decade ago. This is not a rapidly moving target. I was thinking about (and 
in fact started writing last year) a base library implementing the data part 
of the handle graphics objects. This library could easily form the basis of a 
number of visualisation applications that want to implement the handle 
graphics specification.

Maybe a good start would be for me to finish an initial implementation of this 
library?

> 1.b Wouldn't this data have to duplicated in the plugin anyway?
>
> 2. Where will the actual data (i.e. the property values) reside -- in
> the octave type or in the plugin?
>
> If the data is in octave, this could make a very inefficient data
> transfers between the plugin and octave each redraw (e.g. getting the
> data points)

The data would only be in the plugin.

> If the data is in the plugin, which would make it efficient, than it
> should contain some internal representation of the line object, and thus
> the octave type is redundant.

The Octave type is merely an entry into the plugin (which would typically be 
the communication layer to an external visualisation application such as 
OPlot or KV).

My ideas are based around the concept that the Octave type knows nothing apart 
from the ID (or 'handle' in matlab speak) of itself, which is used to 
communcate with the external implementation. The external system is 
responsible for everything, with the plugin receiving and generating 
octave_type objects.

Thus the external system would be responsible for object data, error handling, 
set/get etc.. The burden of implementing the handle graphics specification 
would thus be on the developers of an external graphical application, and not 
within the Octave code base.

The implementation of the Octave handle graphics layer would be simply the 
creation of the basic types, and the implementation of a standard plugin 
system.

All that is thus required is someone to undertake the creation of the Octave 
graphical types. This is a job for someone who knows very well the Octave 
design and code base. I did take a look myself about a year ago, but the 
combination of a lack of time and the lack of clear documentation for 
would-be Octave developers resulted in me abandoning my initiative.

So the question is: is there and experienced Octave developer out there who is 
willing to undertake this job? I've been watching the Octave graphics list 
for some years now, and my experience is that none of the key Octave 
developers seem to be that interested.

Nick