[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
- octave gset, graw, Volker Kuhlmann, 2006/02/24
- Re: octave gset, graw, Søren Hauberg, 2006/02/24
- Re: octave gset, graw, Bill Denney, 2006/02/24
- Re: octave gset, graw,
Daniel J Sebald <=
- Re: octave gset, graw, Quentin Spencer, 2006/02/24
- Re: octave gset, graw, Bill Denney, 2006/02/24
- Re: octave gset, graw, Daniel J Sebald, 2006/02/24
- Re: octave gset, graw, Bill Denney, 2006/02/24
- Re: octave gset, graw, Daniel J Sebald, 2006/02/24
- Re: octave gset, graw, Stefan van der Walt, 2006/02/24
- Re: octave gset, graw, Daniel J Sebald, 2006/02/24
- Re: octave gset, graw, Volker Kuhlmann, 2006/02/24
- Re: octave gset, graw, Daniel J Sebald, 2006/02/24
- Re: octave gset, graw, John W. Eaton, 2006/02/24