octave-maintainers
[Top][All Lists]
Advanced

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

Re: octave gset, graw


From: Daniel J Sebald
Subject: Re: octave gset, graw
Date: Fri, 24 Feb 2006 12:50:40 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

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.

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.  Will it require a lot of maintenance?  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'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.

Dan



reply via email to

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