Re: goals for 3.1

[Daniel J Sebald]

> On Nov 14, 2007 6:52 PM, Daniel J Sebald <address@hidden>
> wrote:
[snip]
> > If the approach I explained in the last post were made to work,
> > i.e., able to send commands to the __plot_stream__ and have
> > whatever is on the other end respond accordingly, then that gives
> > the flexibility needed.  One could write their own __gnuplot_X__()
> > consisting of a dozen commands or less.  If we could write a script
> > as such before 3.0 and verify it works, then post it somewhere that
> > would put the issue to rest for at least the foreseeable future

Shai wrote:

> You are assuming that "whatever is on the other end" will be
> something that works by parsing a stream. This would probably not be
> the case for any backend other than gnuplot

John wrote:

> The problem with this approach is that there might not be a 
> __plot_stream__ in a future version of Octave.


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.  What I'm suggesting (and if there is a better alternative, say so) is that the 
current __go_draw_axes__, __gnuplot_version__, etc. and some script, say, gpcom() for 
"gnuplot command" (a very short little routine) be bundled as a package.  If 
gnuplot is the only such package that uses __plot_stream__ so be it.  Remove the 
__gnuplot_raw__ commands from Octave innards.

Comments:

1) The octave/gnuplot community would then have its little pseudo-standard 
"gpcom()" routine, or whatever it is to be called, that is detached from 
Octave-cvs.  __gnuplot_raw__ is somewhat typing-unfriendly, so few would miss it I'm 
guessing.

2) I recall now why the example I gave previously doesn't work.  "replot" requires data 
in a file and now data is streamed through the pipe itself.  A "redraw" command is in the 
works for gnuplot that will reuse the data it was sent.  I'm not sure how that has come along, 
however.

As for the __plot_stream__, if not a generic interface that uses pipes, what type of generic interface will it be?  I mean, if one 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.  

Or, one could write a set of Octave graphic primitives in C++ (perhaps similar to the 
various elements of __go_draw_axes__) that call some library functions---the 
gnuplot-target code would have a builtin plot stream in which case one would have to 
figure out how to make a "gpcom()" interface to that.  If one goes this route, 
will it mean compiling different versions of Octave to get the desired graphics backend?  
Will it be something like Windows plugins?

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.  Reading the list, sometimes I think 
"yes", sometimes "no".  There is allusion to some better configuration or 
alternative, but what exactly that is hasn't been defined.  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 and for a while (probably quite a long while) the plotting quality won't be the same as 
Matlab.

The __plot_stream__ issue is small.  Is there that bigger question still?

Dan