Re: Oplot

Ole Jacob Hagen wrote:
> Rafael Laboissiere wrote:
> 
>> Since Shai Ayal also manifested himself in this thread, I would like to
>> express my wishes here.  It seems that Ayal's octplot and yours oplot are
>> very similar projects.  The main difference lays on the choice of the GUI
>> toolkit (octplot uses FLTK, while oplot uses QT).  If I could choose, my
>> preference would be GTK, which is the ubiquitous toolkit nowadays.
>>
My reason for choosing FLTK is that it was the smallest toolkit I could 
find which is cross platform. running on Win is very important for me 
since my home system is WinXP and my office system is GNU/Linux (which I 
believe is the opposite of what most people have). It does not take 20 
minutes to compile. If you don't already have it installed, it is very 
easy to install even on slow, old systems since it is small and self 
contained, and you get Mac OSX compatibility as a bonus.
>>
> Developing a gtk-versjon of Oplot, should not be a problem really.

Developing a gtk version of octplot would be quite a large problem :)

>> However, library preferences apart, I am really wondering whether octplot
>> and oplot could be merged.  An abstraction layer would then be defined 
>> such
>> that the new Handle Graphics interface to Octave could be run using any
>> graphical toolkit.  What do you think?
>>
> Do you have comments on this one, Shai Ayal?
> We had this discussion for some months ago....

First, please call me Shai.

Yes, Ole has tried to persuade me to join efforts several months ago 
when I announced octplot 0.1.0. My reasons for not joining are in that 
thread. Basically , I am coding octplot for my own pleasure and learning 
c++, and my personal situation does not allow me to make any commitments 
about my availability (full time job + 2 kids == a lot of very 
unpredictable long interruptions).

About abstraction: I try to do this in the following way in octplot:

Basically any handle graphics package which is compatible with matlab 
syntax and properties should have at least the following primitive 
functions:

set, get, figure*, clf, axes*, cla, line*, text*, delete
*these correspond to objects (which have handles)

octplot supports these primitive commands through octplot_command.oct 
use "help octplot_command" to see all primitives. All higher level 
commands are implemented as m-files outside the octplot application 
code. Currently the following are implemented:

axis, plot, subplot, loglog, semilogy, semilogx, freqz_plot, gca, gcf, 
grid, hold, ishold, contour

contour is a special case since it calls contourl which is an oct file 
and is based on plplot. However both contour & coutourl are totally 
independent of octplot. I believe Ole has already made use of them.

So in principle, If you implement a backend which has these basic 
functions, you could use all the high level functions from octplot, and 
you don't even have to understand c++!

So, my suggestion at abstracting and code reuse is to put all the high 
level commands separately (maybe in octave-forge?) and have each backend 
implement its own low level commands. The high level commands can than 
be shared and maintained by the whole octave community.

Comments ?

	Shai