Re: goals for 3.1

[Shai Ayal]

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
>
> > | The question that often comes to mind is whether it is intended
> > | going forward that Octave have flexibility for multiple graphics
> > | engine support or not.
> >
> > I'm no longer sure whether having multiple backends is really
> > desirable.  If you'd like, revive this discussion:
> >
> >   
> > https://www.cae.wisc.edu/pipermail/octave-maintainers/2007-October/thread.html#4369
> >
> > At least at this point, gnuplot has been sufficiently untangled from
> > the rest of Octave so that replacing it with something else only
> > requires replacing drawnow and the functions it calls.  I have no
> > desire to undo that clean separation by encouraging people to embed
> > gnuplot-specific things in their Octave code.
>
> I wasn't suggesting that.  By "no longer sure", do you mean you are on the 
> fence wondering?  Or saying that there will definitely be a day when Octave 
> can't support anything other than some internal graphics?
>
>
> > | If there
> > | is going to be a choice of one graphics library, compiled internal
> > | to Octave and nothing else, that means a break has to be made
> > | somewhere
> >
> > I don't think I understand what you mean by "a break has to be made".
> > To introduce a new graphics library, we replace drawnow and the
> > functions it calls with something else.  It can be optional at first,
> > but at some point, I expect that the new code will become the default
> > and preferred way to do graphics because it's likely that only the new
> > code will be able to properly support all the graphics properties and
> > features.
>
> What is the "new code", the matryoshka handles that currently will be 
> released as part of 3.0?  Or some new, as yet not written, code that makes 
> drawnow() an internal routine?
>
> > | and for a while (probably quite a long while) the plotting
> > | quality won't be the same as Matlab.
> >
> > 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.

Shai