Re: Octave GUI API: Proposal.

On Sunday 19 December 2004 20:02, Shai Ayal wrote:
> Presto! you have an instant API, no deep knowledge of octave is needed,
> and the responsibility of writing all the interface is now on the
> programmer of each application which is highly motivated to have his
> application fit in the API. We also do not impose a callback structure
> on the applications.

The reason I had for implementing the basic handle graphics objects in Octave 
was to provide the possibility for the external graphics application to 
initiate function callbacks to Octave. For example, the user creates a button 
object in the graphical application window by issuing a command in Octave. 
The button is linked to an Octave function. When the button is clicked, the 
graphical application sends Octave the callback function name. Without this, 
there is no possibility of creating interactive Octave GUIs.

A system with callbacks cannot be implemented using only external files (we 
would need some kind of message insertion mechanism in to the Octave thread). 
Hence I thought the most appropriate solution would be to implement the core 
handle graphics object types (root, figure, axes, line, text, surface, patch) 
in Octave along with an incoming message handler thread. Then, as you 
suggest, everything else coulds be implemented as m or oct files.

Hence:

internal Octave types linked to plugin and message handler:
   1. Base objects: figure,axes,line,text,surface,patch

m or oct files:
   2. Base manipulators:  get,set,delete,gcf,gca,clf,cla
   3. plot,surf,mesh etc..

The bulk of the work would still be common (maintained elsewhere as you say). 
Only the base object implementation would be unique to each visualisation 
application (which it would have to be anyway, even if we implement the 
Octave end as m files), and even then it would share a common built-in Octave 
interface leading to the application's plugin.

There is another advantage to this approach. It allows the use of a syntax 
more appropriate to an object based system:

For example, instead of:
   mysurface = surface(X, Y, Z);
   set(mysurface, 'AmbientStrength', 0.5);
   set(mysurface, 'DiffuseStrength', 0.8);
   strength = get(mysurface, 'AmbientStrength');

One would say:
   mysurface = surface(X, Y, Z);
   mysurface.AmbientStrength = 0.5;
   mysurface.DiffuseStrength = 0.8;
   strength = mysurface.AmbientStrength;

This type of syntax seems to be prefered by some other people as well:

http://www.octave.org/mailing-lists/octave-graphics/1999/17

> As I've said before, if there is a better way of doing things, I think
> we should use the better way with the idea of being able to provide a
> compatibility layer.  For example, would
> 
>   gui_object.background_color = "blue";
>   gui_object.geometry = "...";
>
> jwe

As John mentioned back in 1999, the set/get mechanism could be provided as a 
compatibility layer.

However, as I said in my past email, I've watched the same or similar 
discussions take place over a period of 5 years, and no one has done anything 
in this time!

To begin, we need to implement the core graphical object types in the Octave 
code base by creating something similar to an non-configurable octave struct.

Example:

axes
    aLim                (double[2])
    ambientLightColor   (double[3])
    cameraPosition      (double[3])
    cameraTarget        (double[3])
    cameraUpVector      (double[3])
    cameraViewAngle     (double)
    cLim                (double[2])
    color               (double[3])
    dataAspectRatio     (double[3])
    gridLineStyle       (enum)
    lineWidth           (double)
    plotBoxAspectRatio  (double[3])
    tickLength          (double[2])
    xColor              (double[3])
    xLim                (double[2])
    xTick               (double array)
    xTickLabel          (string array)
    yColor              (double[3])
    yLim                (double[2])
    yTick               (double array)
    yTickLabel          (string array)
    zColor              (double[3])
    zLim                (double[2])
    zTick               (double array)
    zTickLabel          (string array)
  
The contents can be modified, but not configured (i.e. the user cannot add 
other objects into the object as with a normal struct).

After we have the core objects, the rest will naturally follow with the 
community writing m and oct files for the higher level functionality. The 
callback manager can wait till later.

Nic