Re: goals for 3.1

[Daniel J Sebald]

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.)


> > > 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