Re: Handle graphics again

[Ole Jacob Hagen]

Hi,

Once again. :-)

Oplot is shipped with an independent Handle Graphics implementation
called Props.

Look at Oplot here http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/
and Props http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/props

 A demonstration of features supported by Props are supplied in octave
subfolder http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/props/octave/

After compilation of props folder, you can enter this folder and run sh
run_octave.sh
Now you can experiment with the p-prefixed functions created in the
octave folder.
This involves NO visualisation at all. Please play with pget, pset,
pline, psurface and so on. There is a bug in these p-prefixed functions,
but they are not present in the Oplot version.

Read some code here:

http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/props/octave/props.cc?rev=1.18&view=auto
to unveil the magic in props.cc!!!


Props could be rewritten to fit Octave's requirements and coding style
as well, and be shipped with Octave, and used by ALL visualisation
applications for Octave.

The code has been made, and it works pretty well.

I will try to fix the documentation of Oplot and Props as soon as possible.
I am now developing Oplot, both with new axes system and better
rendering system, far better postscript generation,  and migrate Oplot
from Qt3 to Qt4.

When this is done, there are possibilities to join forces with author of
Octave-GUI to create the ultimate octave-gui supporting m-file editing,
command history, command windows, plotting, handle graphics editor, and
handle graphics inside.  And this is a freely available Qt4 application.

In the present Oplot implementation there is a communication interface
between Octave and Oplot, since they are communicating with sockets.
This is a drawback. If Octave-GUI and Oplot becomes one application,
this communication interface would be gone.....And the drawback is also
gone.

Doesn't this looks promising? First I have to reach my milestone....

Octave-GUI developed by Sebastien is very promising indeed.

Cheers,

Ole J.










John Swensen wrote:
> Unfortunately, I have to side with Shai on this one.  I see the document
> portion of the handle graphics as the fairly trivial portion.  When I
> was working on this more extensively, I created a solution nearly
> identical to that of Ole using C++.  The implementation of all the
> "document" side of things could *almost*  be done by  parsing the web
> pages of the Handle Graphics Property Browser and auto-generating code
> using the Props framework.  It was also much much easier to implement
> the get/set for each "type" of object and enforce restrictions on values
> and such using simple inheritence and other OO tactics.
>
> On the other side, I think it makes very much good sense to do the
> viewer implementation in m files so others can contribute.  This is the
> part where we make it behave like the popular brand.  If someone sees
> something that acts different than they expect, it makes sense for all
> the .m programmers out there to be able to work on making it act how it
> should.  Since there are binding for m->C/C++ for a plethora of toolkits
> (gtk, fltk, qt, tkinter), the choices are endless and I'm sure each one
> would have its trades.
>