octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: goals for 3.1


From: John W. Eaton
Subject: Re: goals for 3.1
Date: Wed, 14 Nov 2007 22:18:53 -0500

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.

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

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

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

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

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

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]