Re: handle grapics with Document/View design

[Shai Ayal]

While I am enthusiastic about the simplicity of using m-files for as
much as possible I am still a little uncomfortable about the
"Document" being a global variable visible to everyone. I think this
is too big a price to pay, especially since, as I understand from the
code, It is not such a simple data structure, and any attempt to
modify it directly will probably result in it's corruption.

Isn't there some way to make it "private" and accessible only through
get/set? perhaps only putting the structure and the access methods in
a dld, and keeping all the other stuff in m-files?

Shai

On 10/14/05, John W. Eaton <address@hidden> wrote:
> On 18-Aug-2005, John W. Eaton wrote:
>
> | On 18-Aug-2005, Brian Blais wrote:
> |
> | | In my implementation of the gui for octave (at
> | | http://web.bryant.edu/~bblais/octave) I have just that: an octave
> | | structure array, and there is a "handle" field.  Then I do:
> | |
> | |    handles=[uiobjects.handle];
> | |    idx=find(handles==h);
> | |
> | | to find the actual index to the array.  It is pretty fast.
> | |
> | | all of the set/get operations do the same thing.
> |
> | So all the uiobjects are in a flat structure array?
>
> Thanks for the above tip.
>
> I've given handle graphics some more thought over the last couple of
> days and written some example code that implements bare-bones versions
> of
>
>  axes  close     delete   figure  gcf  isfigure  line
>  clf   closereq  drawnow  gca     get  ishandle  set
>
> Only the minimum number of properties are handled (just enough for
> proof of concept).
>
> Everything is implemented in .m files.  I'm using gnuplot to display
> the graphics and the connection is managed entirely inside the .m
> files with popen/pclose.  Commands and data are sent down the pipe
> with fputs and fprintf.  There are no temporary files.
>
> On my system (a 1.4GHz AMD system running Debian) a line plot with
> 1000 points takes around 0.4 seconds to get on the screen.  I think
> that's OK given that it is all .m files.  It will be slower if there
> are more properties to handle, but maybe it will still be usable.
> Performace is very bad if the number of lines approaches maybe 40 (so
> you wouldn't want to create a drawing by calling line() for every
> segment).  If performance is a big problem, critical sections can
> always be translated to C++, but I think the real problem here is
> gnuplot (you can demonstrate the poor performance running gnuplot and
> plotting simple functions from the gnuplot command prompt).  In any
> case, I'd prefer to keep as much as possible in the scripting
> language, at least for now.
>
> To hook up something other than gnuplot, only a few changes are
> required.  The biggest thing is that you need to implement your own
> drawnow function that examines the elements of the uiobjects list
> corresponding to the current figure, deals with the properties, and
> displays the graphics.
>
> When GUI objects are added to the mix, we will need to think about how
> events and callbacks should be handled, how to keep the GUI working
> when Octave is crunching away on some computations, etc.  I haven't
> worried about that much yet.
>
> Since the list of graphics objects is just a global variable, I think
> we will need some way to prevent a user from wiping it out.
>
> If you are interested in looking at this code, it will be available
> for a short time at
>
>  http://jbrwww.che.wisc.edu/~jwe/handle-graphics.tar.gz
>
> Unpack it, cd to the handle-graphics directory that it creates, run
> Octave (it should work with 2.1.69 as well as 2.9.x), and try
> something like
>
>  line (rand (100, 1), rand (100, 1))
>  drawnow
>  figure (2)
>  line (rand (100, 1), rand (100, 1))
>  drawnow
>
> (in most cases, you need to issue drawnow commands explicitly, since
> it is not hooked in to Octave's command loop yet).
>
> I'm sure there are some bugs, but it should at least show the kind of
> design I have in mind.
>
> Comments welcome.
>
> jwe
>
>