octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: patch to configure.in & aclocal.m4 for graphics libraries


From: Shai Ayal
Subject: Re: patch to configure.in & aclocal.m4 for graphics libraries
Date: Sun, 16 Sep 2007 15:55:37 +0200

On 9/16/07, Michael Goffioul <address@hidden> wrote:
> On 9/16/07, Shai Ayal <address@hidden> wrote:
> > > Yes I agree that opengl+gl2ps is ugly and for plotting in octave gnuplot
> > > is still the only way to go (the graceplot interface seems a deadend).
> > > Given your statement above, it seems inevitable that there will be at
> > > least to different renderers. So the important thing now should be to
> > > get the frontend right and the API to the backend fixed.. Bill Denney I
> > > believe worked on an API (found on the wiki), but the split between the
> > > backend and frontend is not clear.
> >
> > Bill Denney worked on defining the minimal set of objects/properties
> > that should be supported by a backend. Now that octave has it's own
> > object tree, I think this has become the de-facto minimal set of
> > objects/properties. We should work to add in as many
> > objects/properties as possible of course.
> > As for the API for backends, It is in development now and consists of
> > accesor functions for objects/poperties. Some other parts are missing
> > (listners etc...) and I would be happy for some contributions.
>
> Up to now, only the rendering part has been considered. While defining
> the octave handle system, I think you should also consider UI elements,
> even a very limited subset (a pushbutton with basic properties like
> position, units, font/color and callback). This might have some impact
> on your arhcitecture and the interaction between octave handle system
> and the backend (you'll also need some kind of synchronization between
> octave objects and the UI objects used in any toolkit).

I'm not sure by what you mean "synchronization", but I agree that the
architecture be able to communicate back to octave -- calling callback
functions, and other functions -- even w/o UI, the renderer has to
convey to octave that the "close" button of a figure window has been
pushed, thereby deleting the figure and it's children.
I think that if the renderer is linked against octave (i.e. an oct
file) then these issues become simpler.

Shai


reply via email to

[Prev in Thread] Current Thread [Next in Thread]