Re: goals for 3.1

[Shai Ayal]

On Nov 14, 2007 6:52 PM, Daniel J Sebald <address@hidden> wrote:
> John W. Eaton wrote:
> > On 14-Nov-2007, Joseph C. Slater PE, PhD wrote:
> >
> > |
> > | On Nov 13, 2007, at 2:11 PM, John W. Eaton wrote:
> > |
> > | > I'd like to have a fairly small list of key goals for 3.1 so that we
> > | > can make another release 6 months or so after 3.0.  Here's my current
> > | > list:
> > | >
> > | > <snip>
> > | >
> > | >  * Eliminate __gnuplot_X__ functions from Octave
> > | > <snip>
> > | >
> > | > Comments or suggestions?
> > |
> > | Is there a tangible benefit to doing this?
> >
> > For me, there are at least two.  First, it eliminates some klugy code,
> > so makes maintenance easier.  Second, since these functions no longer
> > have any effect on the output of plots created with the Matlab
> > compatible plotting interface, removing them will avoid some
> > confusion.
>
> I agree with that.  It is just confusion.  In fact, why not get rid of them 
> for 3.0?  That would give a clean break for transitioning from the old way of 
> interacting with gnuplot to the new way of interacting with gnuplot.
>
> >
> > | Matlab compatibility. Maybe I'm wrong, but I think the existence of
> > | this level of control is a plus.
> >
> > Being able to specify details is nice, but tying it specifically to
> > gnuplot is a big minus.
> >
> > Since the graphics backend may not always be based on gnuplot, I don't
> > see how we can expect to support all the output formats that gnuplot
> > can unless someone volunteers to write the code.
>
> 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

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

Shai