octave-maintainers
[Top][All Lists]
Advanced

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

Re: graphics-branch in CVS


From: David Bateman
Subject: Re: graphics-branch in CVS
Date: Thu, 07 Dec 2006 22:13:54 +0100
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

John W. Eaton wrote:
> I created a separate CVS branch called graphics-branch for the code
> that I've been working on.  Check that out if you'd like to see what
> direction I'm heading in.
> 
> The previous code was moving toward storing the complete data for all
> figures in a set of global data structures, all indexed by the current
> figure and subplot location, etc.  This approach was quickly becoming
> unmanageable, and was just not going to work for some things.
> 
> The new version rearranges that data structure so it looks more like
> Matlab Handle Graphics (TM) objects.  Everything is still implemented
> in .m files, so it is somewhat slow.  The current code is primarily
> derived from what I announced on this list:
> 
>   http://velveeta.che.wisc.edu/octave/lists/octave-maintainers/2005/853
> 
> along with some ideas and code from Bill Denney's version.

There seems to be some other things that might be taken from Bill's
code, with the most notable being patch.m...

> I chose to continue with this code rather than adopt something like
> OctPlot because OctPlot does not do 3d graphics.
> 
> For this latest revision, I've only implemented the properties that
> are necessary for the graphics functions we currently have in Octave
> (see below for some things that are not yet working).
> 
> I think of this code as an intermediate solution to graphics problems
> in Octave.  It gives us a path forward so that at least some handle
> graphics code written for Matlab can work in Octave, and it should
> allow us to solve some long-standing problems with plotting.  For
> example, we should be able to plot 2d figures on top of images, make
> the print function work for subplots, and (with a little more work)
> allow line widths and styles to be set.

One minor thing I'd like to see changed is to separate the backend
directory. My reasoning is that although not strictly needed to
implement another non gnuplot backend, if not all of the backend
functions are implemented then an rmpath on the backend directory will
prevent a remnant of a gnuplot backend function doing something
unexpected. Then again the backend developer can always supply dummy
functions for all backend functions.

Cheers
D.



reply via email to

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