Re: octave gset, graw

[Bill Denney]

On Fri, 24 Feb 2006, Quentin Spencer wrote:

> Daniel J Sebald wrote:
> > Could the group be more explicit about the roadmap for graphics?  I 
> > listen to John I hear one thing, other people say some other thing.

I'm not positive, but here is my guess:  handle graphics will be the
method used in 3.0.  When that happens, there will be a gnuplot back-end
that you can probably still tweak with __gnuplot_raw__ and other similar
commands.

> > I understand some people want handle graphics, but I won't necessarily 
> > want to use that.  I've said before to the list that I find simply 
> > typing a command like "graw('set size square\n')".  Perhaps I'd migrate 
> > back to handle graphics but I always thought it cumbersome in the fact 
> > that one has to figure out first through parent/child/grandchild what 
> > it is they want to change.  HG commands were always something I'd save 
> > for the very end.
>
> Cumbersome, maybe, but I always found it more intuitive when I want to 
> change a low-level setting than trying to search through gnuplot's 
> documentation. The other motivation for HG of course is "compatibility 
> with the other brand".

I would say that searching octave documentation for how to plot something 
in octave is far more intuitive and less cumbersome than searching gnuplot 
documentation for how to plot something in octave.  Also, I have before 
written scripts that output data that is then input by a gnuplot command 
script.  Using octave commands to make octave plots seems the least 
cumbersome.

> > Also, retaining the "graw()" (which I understand now is meant to be 
> > graphics raw, not gnuplot raw) gives some fine control that might not be 
> > found in handle graphics.  For example, will there be ways in the print 
> > command to do something like
> >
> > graw('set term gif animate 0.1\n')
> >
> > ?  Probably not.  Why?  Because the way Matlab works now, one is forced to 
> > first draw a plot and then change its properties as opposed to setting the 
> > properties and then doing the plot.  If I can set the properties first, 
> > with a command like above, I can string together a series of plots into an 
> > animation.

There are other ways to string together plots into animations.  I 
personally plan to make sure that there is an SVG output.  With SVG it is 
trivial to convert it to a gif animation.  I may make that an option.  I 
don't see how it makes it easier to make an animation by putting the 
command before or after making the plots.

> > If there is an internal graphics engine for Octave, then HG would seem 
> > fairly easy conceptually.  But if the idea is to support multiple 
> > graphics engines will life be so simple?
>
> I think this is why John has advocated implementing an internal handle 
> graphics engine written as m files that interface with low-level 
> plotting functions unique to each graphics backend. It will of course 
> start with gnuplot as the default, but theoretically someone wanting a 
> different output generator could write the low-level interface functions 
> and use the same handle graphics fron end.

I agree with this.  That is why I am trying to make sure that the 
interface for the users and the backend developers is defined.  If I can 
make a set of handles and then use it to make a plot on the screen, then 
export it to an SVG, then make an animation out of it, ... then I'm going 
to enjoy plotting significantly more (which is currently what I think is 
the biggest weakness in Octave).

> > I'm just wondering if the roadmap here is to make fine tuning plots 
> > slightly more difficult and inadvertently take away some flexibility. 
> > I guess what I'm wondering is whether __graw__() is part of the roadmap 
> > for graphics.
>
> I was under the impression that __gnuplot_raw__ isn't going away, but that 
> the change was done to discourage it's use in favor of the high-level matlab 
> functions, and eventually the HG implementation. I think it was partly in 
> response to the number of newbies on the mailing lists trying to do things 
> with the gset commands that could be done with simpler commands using higher 
> level matlab-compatible functions that were already available.

Right, I think that __gnuplot_raw__ will continue to exist though it will 
probably be moved another step away from the common users into part of the 
gnuplot graphics backend.

Bill

--
"My mind is so numb and braindead; I feel I've just attended a three day
seminar on the future of plumbing."
  -- Rimmer, _Red Dwarf_ Series 8 Ep 1