Re: desired features for gp backend?

[John W. Eaton]

On 17-Jun-2009, Daniel J Sebald wrote:

| John W. Eaton wrote:
|
| > I've said many times that I think that trying to implement the gnuplot
| > syntax in Octave was a big mistake.  I wish I had never done it.
| 
| I'm not sure what the alternative would have been at the time, but
| that's the route you chose.

The other alternative would have been to completely hide gnuplot
behind some plotting functions without introducing any new syntax.

| > I have no interest in doing this because it ties your plotting
| > commands to gnuplot, and introduces portability problems for people
| > who don't want to use gnuplot for plotting.
| 
| Sort of, but not really.  set(fig, 'postplot', ...) says nothing
| about what is at the other end.

I've always assumed that you wanted to pass literal gnuplot syntax as
the postplot property.  To me, that ties you to gnuplot.  If you mean
for the postplot property to just be some generic new property that
could be handled by any plotting engine, then I don't see the point.
It seems to me that we might as well just improve the existing plot
properties or introduce specific new properties for features that are
missing.

| The rule would be that the option
| is "hidden", i.e., can't be used as valid syntax in any scripts or
| packages.

What do you mean by that?  What does "scripts or packages" mean to
you?  If not in scripts or packages, where would it be used?

| The analogy is the startup file of Octave or other
| programs; a means to initialize or cleanup the plotting engine.

Then wouldn't

  initialize_plotting_engine ()
  cleanup_plotting_engine ();

be all you need, and leave it up to the plotting engine to do its
magic?  Why is a property and corresponding value needed?  How can you
ensure that the value of the "postplot" property is meaningful for
every possible plotting engine?

jwe