Re: octave gset, graw

[Quentin Spencer]

Daniel J Sebald wrote:

> Bill Denney wrote:
>
> > On Fri, 24 Feb 2006, Volker Kuhlmann wrote:
> >
> > > The manual and FAQ are dated 1998 - no help there.
> >
> >
> >
> > I'm working to update the website.  Hopefully in the next week it 
> > will be more help there.  If you feel this is a big hinderance, 
> > please feel free to contribute to make the documentation easier to 
> > find and more up-to-date.
> >
> > > Please don't remove the mechanism to tune the plot output before 
> > > providing something better.
>
> Will putting a script file "graw.m" in your personal script directory 
> that does
>
> function graw(varargin)
>
> __graw(varargin)__
>
> help any?
>
> > This is being handled currently by the implementation of handle 
> > graphics. The effort is trying to make the plot system modular (there 
> > will be one set of octave functions to set the properties that can 
> > interact with any number of back-ends to draw the plots).  You can 
> > see some results in this with the Octaviz and Octplot graphics 
> > packages (http://www.gnu.org/software/octave/related.html).
> >
> > So, the code is not going away yet, and it won't go away until you 
> > are able to better manage your plots.
>
>
> 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 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".

> 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.
>
> Handle graphics is a big project.

Yes, it is. I think that's part of the reason for so many conflicting 
proposals and no complete solution yet.

> Will it require a lot of maintenance?

I think it depends on how it's implemented.

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

-Quentin