From graphics-request at octave dot org Mon Nov 29 13:30:21 2004 Subject: Re: Oplot From: Shai Ayal To: Ole Jacob Hagen Cc: graphics at octave dot org Date: Mon, 29 Nov 2004 21:19:10 +0200 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