Re: goals for 3.1

[Shai Ayal]

On Nov 15, 2007 6:55 AM, Daniel J Sebald <address@hidden> wrote:
>
> Shai Ayal wrote:
> > On Nov 15, 2007 5:51 AM, Daniel J Sebald <address@hidden>
> > wrote:
> >
> >> John W. Eaton wrote:
> >>
> >>> On 14-Nov-2007, Daniel J Sebald wrote:
> >>>
> >>> | Note that I said foreseeable future.  What I am proposing would
> >>>  | require a script file of, say, a half dozen lines?  That'd be
> >>> not | much effort wasted if the scheme changes some day.
> >>>
> >>> The reason I don't want this is not that it would be hard to
> >>> implement, but that it would encourage users to further depend on
> >>>  details specific to gnuplot to produce plots.  That will cause
> >>> trouble in the future if (or more likely, when) the default
> >>> plotting engine is not based on gnuplot.
> >>
> >> Well, yes and no, and why is this a bad thing?  I suspect few
> >> really enjoyed writing gnuplot commands through Octave over the
> >> past few years, and will welcome the matryoshka handles interface
> >> and might even be willing to write support for it rather than
> >> circumventing through gpcom().  (I've warmed to matryoshka graphics
> >> now that I see the gca() routine as a shortcut.)  The package
> >> should have a non-compatibility disclaimer of course.
> >>
> >>
> >>
> >>> | As for the __plot_stream__, if not a generic interface that
> >>> uses | pipes, what type of generic interface will it be?
> >>>
> >>> If I understand the question correctly, the interface to the
> >>> plotting backend is that you provide a replacement for drawnow,
> >>> preferably using the plot properties that Octave manages.
> >>
> >> Well, that is what I had in mind, but sometimes I'm left wondering.
> >> (I went along with the drawnow idea at the time and thought it was
> >> a fine idea.)
> >>
> >>
> >>
> >>> | wants to interface to some other graphics library it would be
> >>> easy | enough to write something that uses a plot stream as
> >>> though it were | calling library functions.
> >>>
> >>> Doesn't that assume that the plot stream can accept the gnuplot
> >>> command language in order for it to work properly with the
> >>> function that you propose to allow gnuplot commands to be sent to
> >>> the plot stream?  I don't see that as likely for any backends
> >>> other than the current one that is based on gnuplot.
> >>
> >> Well, a plot stream is going to be needed for gnuplot.  Is there
> >> some way of building a pipe outside of Octave's C++?  But you
> >> haven't explained how other packages are going to integrated to
> >> drawnow().  drawnow() will become internal?  Then what.
> >
> >
> > I'm not sure what you mean by internal, but the way I see it drawnow
> > will become an oct file which will read the "matryoshka" handle tree
> > and render it (on screen, or to some file). In principle there could
> > be many implementations of drawnow which will rpoduce output in many
> > different formats, although I'm not sure what will actually happen in
> >  practise
>
> Oh, I'm not very familiar with Oct files.  OK, so would it be possible then 
> to write an Oct file that builds the pipe stream handle that the gnuplot 
> version of drawnow() requires?  That would remove __plot_stream__ from the 
> properties but make it still accessible to the underworld some how.  Or am I 
> completely misunderstanding Oct files?  (I'm not sure what I mean by internal 
> either, other than if it is a library it has to be compiled somehow and there 
> is the desire of making the property interpretation faster... searching old 
> threads I see now you mentioned Oct file before.)
>

an oct-file is a compiled c++ function file for octave, and is used to
define octave functions as an alternative to using an m-file with the
m(?) language. Practically what this means is that the current drawnow
function just has to be renamed to something more gnuplot_specific,
(e.g. __gnuplot_drawnow)  and can be used along with other drawnow
functions ( e.g. __newbackend_drawnow).
I propose that each figure will have a property named "backend" which
can have one of several values -- "gnuplot","newbackend", "jhandles",
....). Using this value, the appropriate backend will be called, vie
the appropriate drawnow function to render the figure. This way you
can have co-existence of many backends, and specifically, we will not
have to abandon gnuplot.
Each of these back-ends can have specific functions, but these
functions should not be in core-octave, and should be used with care
since they would break inter-oparability.

Shai

> >>> It's not the same as Matlab now, is it?
> >>
> >> Right, but in some ways it is better, because of the various output
> >> formats.
> >
> >
> > I agree that it will be very hard to live up to the many output
> > formats of gnuplot, But I hope we will be able to natively produce at
> >  least eps, png and eps with latex code for the labels. From these
> > formats I think we can convert using external applications to many
> > other formats, both vector and bitmap based.
>
> Well, maybe that could be a 3.1 goal then, i.e., an example octplot graphics 
> interface via Oct file that could be used as a template for gnuplot and 
> others.
>
> Dan
>