octave-maintainers
[Top][All Lists]
Advanced

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

Re: goals for 3.1


From: Shai Ayal
Subject: Re: goals for 3.1
Date: Thu, 15 Nov 2007 16:40:55 +0200

On Nov 15, 2007 11:48 AM, Daniel J Sebald <address@hidden> wrote:
> Shai Ayal wrote:
>
> > an oct-file is a compiled c++ function file for octave, and is used
> > to define octave functions as an alternative to using an m-file with
> > the m(?) language. Practically what this means is that the current
> > drawnow function just has to be renamed to something more
> > gnuplot_specific, (e.g. __gnuplot_drawnow)  and can be used along
> > with other drawnow functions ( e.g. __newbackend_drawnow). I propose
> > that each figure will have a property named "backend" which can have
> > one of several values -- "gnuplot","newbackend", "jhandles", ....).
> > Using this value, the appropriate backend will be called, vie the
> > appropriate drawnow function to render the figure. This way you can
> > have co-existence of many backends, and specifically, we will not
> > have to abandon gnuplot. Each of these back-ends can have specific
> > functions, but these functions should not be in core-octave, and
> > should be used with care since they would break inter-oparability.
>
> I see.  In theory then, John's code for building the __plot_stream__ fid's 
> and opening the pipes could be moved to some cc file called 
> __gnuplot_drawnow__.cc.  Rather than __plot_stream__ being part of the figure 
> properties, it could be a linked list of (term, __plot_stream__).  Then how 
> about a similar Oct file routine __gnuplot_f2s__(term) that returns the 
> associated plot stream?  Those two would both need to be .oct files for 
> __gnuplot_f2s__ to access the C++ variables inside __gnuplot_drawnow__.oct.
> So, bundled in the package would be:
>
> __gnuplot_drawnow__.oct
> __gnuplot_f2s__.oct
> __gnuplot_version__.m
> __gnuplot_close_all__.m    (currently called __go_close_all__.m)
> __gnuplot_draw_axes__.m    (currently called __go_draw_axes__.m)
> __gnuplot_draw_figure__.m  (currently called __go_draw_figure__.m)
>
> The m-scripts would require minor tweaks.  Pass in the term number and first 
> line be
>
> __plot_stream__ = __gnuplot_f2s__(term);
> if (__plot_stream__ < -1)
>     return;
>
> I replaced the "go" in the files with "gnuplot" because I think, from the 
> previous discussion, that there won't ever be a need for __go_draw_figure__ 
> other than for gnuplot.
>
> Now, to switch the graphics engine, would all that is required be to simply 
> create an operating system link:
>
> drawnow.oct -> __gnuplot_drawnow__.oct
>

I would say drawnow.m -> __gnuplot_drawnow__.m (I think it would need
minimal changes)
remove the __plot_stream__ property
add the "backend" property which is a string containing the backend name
add a generic drawnow which is basically:
eval (sprintf ("__%s_drawnow__ (gcf ());",get (gcf (),"backend")));

and now to switch the graphics engine, all that would be necessary is:
set (gcf (), "backend" , "gnuplot");

Shai

> ?
>
> Would that move in the desired direction John?
>
> Dan
>
>


reply via email to

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