From octave-maintainers-request at bevo dot che dot wisc dot edu Wed Jan 21 19:56:42 2004 Subject: Handle Graphics and visualisation applications in Octave. From: =?iso-8859-1?q?Ole=20Jacob=20Hagen?= To: octave-maintainers at bevo dot che dot wisc dot edu Cc: octave-graphics at bevo dot che dot wisc dot edu Date: Wed, 21 Jan 2004 19:44:00 -0600 Hi. There is a lot of development going on in replacing Gnuplot as visualisation application. There are following graphics systems available to Octave: 1. Gnuplot 2. epsTk a postscript toolkit for octave and matlab. 3. Kmatplot, renamed to Qmatplot. 4. Knewplot 5. Plplot 6. Grace And these are coming; 1. KV (Kvisualizer, Nick Smethurst) 2. Octaviz (Dragan Tubic et. al) 3. Oplot++ (Ole J. Hagen, Hans O. Hagen) Since KV, Octaviz and Oplot++ will support MATLAB's Handle Graphics, we should collaberate in how to solve this matter. There is no point in re-inventing the wheel, and try to limit Octave to just one visualisation application. Limitation to just one visualisation application can cause panic and forking of the existing Octave. I believe that an user should decide which visualisation application, he wants to use, since taste and flavour is personal. Some are using Gnuplot, and others are using Grace. Therefore, we should collaberate in developing a good Handle graphics solution in Octave. Even Gnuplot has some "handle-graphics"-similar commands, which can be simulated to be Matlab Handle graphic objects. Too bad, there is no two-way communication between gnuplot and octave. I am working out a little paper, with a suggestion how to solve this problem. It is pretty much based on that: 1. Octave treats handle graphic objects as cell/struct arrays internally. 2. Octave gets h-g objects from visualisation application, since this is most naturally. I believe that even Matlab is doing the same. 3. Octave has a native implementation of h-g objects. 4. Each visualisation application makes their unique high-level and low-level drivers. Explanation of 4: What I mean that Octave could have a built-in variable called use_plot_engine='......', which can be changed runtime and can take the following values: grace, oplot, knewplot,qmatplot, octaviz, and it's default value are gnuplot. In my Octave-distribution I've got m-files for plotting in: /usr/share/octave/$VERSION/m/plot. What if each visualisation application creates following folder: /usr/share/octave/$VERSION/graphics/. Please note that graphics folder should be a new folder in /usr/share/octave/$VERSION. This change is caused by that Octave searches recursively in it's search path, and that /usr/share/octave/$VERSION/m/plot should be replaced with /usr/share/octave/$VERSION/graphics/plot example: use_plot_engine='octaviz' octaviz: /usr/share/octave/$VERSION/graphics/octaviz use_plot_engine='kv' KV: /usr/share/octave/$VERSION/graphics/kv use_plot_engine='plot' // default value Gnuplot: /usr/share/octave/$VERSION/graphics/plot use_plot_engine='oplot' Oplot: /usr/share/octave/$VERSION/graphics/oplot These folders should then contain high-level drivers, which calls the low-level drivers for the visualisation application that are used in present time. I am developing Oplot++, which will, if accepted by community contain same files in /usr/share/octave/$VERSION/graphihcs/oplot as in existing /usr/share/octave/$VERSION/m/plot, but using different low-level drivers. Example of low-level drivers could be: oplot_plot.oct, oplot_set.oct, oplot_get.oct, oplot_title.oct, oplot_contour.oct and so on.... Then we need to solve h-g object creation and processing in Octave. This might be also be solved as a low-level and high level driver strategy, as done with plot.m which calls oplot_plot.oct to plot a graph. This is not a very good solution, that each visualisation application shall have their own h-g object implementation, since I believe that Octave should have a native implementation of h-g objects itself. This can be done, if we rename set and get routines to be seth, and geth, and makes a set.m and get.m, as high-level functions, which can be found in /usr/share/octave/$VERSION/graphics/oplot, if oplot is used. The set.m and get.m, will then communicate with Oplot and refreshing visualisation, and updating octave internal h-g objects. Suggestions? Is this feasible John? I will try to implement this. Hopefully it will work.... I'm very optimistic about it, though. Thank you for reading this email. Cheers, Ole J. ______________________________________________________ Få den nye Yahoo! Messenger på http://no.messenger.yahoo.com/ Nye ikoner og bakgrunner, webkamera med superkvalitet og dobbelt så morsom