Re: goals for 3.1

[Daniel J Sebald]

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.


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

Dan