From octave-maintainers-request at bevo dot che dot wisc dot edu Tue Nov 11 02:48:02 2003 Subject: Handle Graphics implementation in Octave. From: =?iso-8859-1?q?Ole=20Jacob=20Hagen?= To: octave-maintainers at bevo dot che dot wisc dot edu Date: Tue, 11 Nov 2003 09:47:45 +0100 (CET) Hi. This message can also be found in octave-graphics-list, but since maintainers-list is read more often, I will post it here as well. Why are people always reading maintainer list, and not checking postings at graphics list? I would suggest people to check out the graphics sections as well. To Nick: Oplot++ is coming around. Have to write code to visualise plottings from scratch, since this have not been implemented in Coin yet, that's why my progress is slow. But fortunately my progress in number of codelines are pretty good. ;-) How far have you (Nick) come with your implementation of handle graphics in kvisualiser? Remember that we might be required to make a new octave_value type, which works pretty much as struct arrays, since set/get mechanisms in Matlab's handle graphics can be manipulated like this: h = plot(x,y); handle =get(h); handle.XData will list x-coordinates of curve. This feature should be implemented. What about the other way? Should it be possible to set handle graphics objects in a similar way? example: h = plot(x,y); gca_handle= get(gca); gca_handle.XLabel = 'x-Axes'; This would be nice, wouldn't it? I wonder if Matlab (R14) offers this functionality. We should also strive for a handle graphics solution where an user can easily change both transport method, and visualisation application. This will require forking of a child process....the child process is the visualisation application. So, how can a generic handle graphics, wich supports different communications schemes with forking work? Well, this is a challenging question, which require a good solution. Nothing is impossible. We can divide handle graphics solution with communication to external application such as Oplot++ or kvisualiser into 3 units: 1. Handle graphics layer, where handle graphics are implemented. 2. Interface layer to external applications. 3. Transport layer, which decides wether sockets (tcp/ip, udp, local), pipes can be used. The core handle graphics routines, and objects should be handled by Octave, maybe be within core of Octave as NDArray is. Then we need some kind of interface level, which will interface hande graphics to the correct communication protocol, wether it's pipes, unix domain socket. As I see it now, shared memory is very hard to solve with two separate application, where visualisation-application is forked, or it might be a process in /etc/init.d, but this is not an option at this stage. The Interface layer require that datas are sent in one way, and one way only => A common communication protocol has to be developed. This protocol has to be based on properties of handle graphics in Matlab. Example: set(gca, 'PropertyName', 'PropertyValue') are sent directly, which means that only one PropertyValue are sent at time. But a user might want to send many parameters such as set(gca, 'PropertyName1', 'PropertyValue1',... 'PropertyName2', 'PropertyValue2',... 'PropertyName3', 'PropertyValue3'); which is allowed in Matlab. This is not a problem really, since we sent these as four messages. 1. send that gca are to be configured. 2. setValue('PropertyName1', 'PropertyValue1'); 3. setValue('PropertyName2', 'PropertyValue2') 4. setValue('PropertyName3', 'PropertyValue3') This will require four transmissions. This will be a base for transport unit. Reason why one property are sent, is to save memory and better control of data transferred. And the protocol is simple, so you don't need to be a PHD to figure it out. The interface unit should be very generic, so people who want's to make their own visualisation-application can develop further on it. How can we solve this? Solution 1: Maybe it should read some environmental variables, like OCTAVE_VISUALIZER_BIN=oplot, OCTAVE_COMMUNICATION=pipes, local, tcpip? These environmental values, can be detected and read by getenv-function. This means that we have almost solved this in a terrific/terrible way. Solution 2: Maybe OCTAVE_VISUALIZER_BIN and OCTAVE_COMMUNICATION should appear in .octaverc instead of being environmental variables? The latter way is always best, I guess. Default values appears in .octaverc, and should be: OCTAVE_VISUALISER_BIN=gnuplot OCTAVE_COMMUNICATION=pipe This will mean that it's possible to change this value from Octave, without quiting an octave session. And thereby change visualisation application. This would be great wouldn't it? Handle graphics would not be disabled if gnuplot is chosen, since newer gnuplot version can use some handle graphics features. set-function has been replaced by gset. Set-function are from now on reserved for handle graphics implementation? It would be recommended that some configuration of Octave in deciding which application to fork. Since Octave needs to fork a child process, since a GUI has not been developed yet....(That's not entirely correct, since goctave and koctave have been developed). The existing gui-frontends are developed in gtk and kde, which will narrow down number of OS's this will work in. Therefore a Qt-solution, or a WxWindows-solution should be used. KDE runs on Windows using Cygwin today, pleas e take a look at http://kde-cygwin.sourceforge.net/ if you don't believe me. Even Qt for X11, is ported to Cygwin. The visualisation-application will then collect datas sent by pipes or sockets, and updating figures. Visualisation-application should also be able to change values of handle graphics objects. This will have some drawbacks, since handle graphics objects are stored in two applications, both in Octave and visualisation-application. The most critical handle graphics objects are XData, YData and ZData. But visualisation library which visualisation application should handle this sufficiently. I've visualised pretty large datasets in Oplot++. And still there is two copies of XData, YData and ZData, both in Oplot and Octave. The main advantage of my suggestion, is that an user can choose freely his own visualisation application, wether it's Oplot++, GnuPlot, QMatPlot, KNewPlot, KVisualiser, QWT-based visualisation-application and so on. I hope that functionality and flexibility are always primary goals in our implementation, if not you should start working at Micro$oft. Some comments, besides the Micro$oft-thing? 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