From octave-graphics-request at bevo dot che dot wisc dot edu Mon Nov 10 17:05:43 2003 Subject: Re: Handle graphics project will start in January 2004. From: Ole Jacob Hagen To: octave-graphics at bevo dot che dot wisc dot edu Date: Mon, 10 Nov 2003 23:59:56 +0100 Hi. 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 the new Release of 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. set(gca, 'PropertyName', 'PropertyValue') are sent directly, which means that only one PropertyValue are sent. 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. Maybe it should read some global variables, like OCTAVE_VISUALIZER_BIN=oplot, OCTAVE_COMMINUCATION=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. Maybe OCTAVE_VISUALIZER_BIN and OCTAVE_COMMINUCATION should appear in .octaverc? The latter way is always best, I guess. Default values appears in .octaverc, and should be: OCTAVE_VISUALIZER_BIN=gnuplot OCTAVE_COMMINUCATION=pipe So a user, can change this value from Octave, without quiting an octave session. Handle graphics will be disabled if gnuplot is chosen, since it has not been developed such "hande graphics"-alike things in Gnuplot.....AFAIK (and I don't know much....:-)) 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. 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 h-g objects are XData, YData and ZData. But visualisation library which visualisation application should handle this sufficiently. In my Oplot, I've visualised pretty large datasets. And still there is two copies of XData, YData and ZData, both in Oplot and Octave. Some comments? Cheers, Ole J. On Sun, 9 Nov 2003 20:24:20 +0100 N Smethurst wrote: > Hi Ole and everyone else. > > Although we have not spoken for some time now, I have still been working on my > application, including the ideas I discussed with you a while back regarding > an Octave graphics system. > > I actually now have a website. There is also some information there about the > plugin concept for an Octave graphical system (more needs to be added > though). The website address is kvisualiser.free.fr > > The more I have pondered over the original idea, the more I have come to > realise that the basic implementation of low level object types in Octave > would be relatively easy. I am beginning to conclude that the bulk of the > work would be in the user end high level plotting scripts and perhaps any > exotic communication methods that people may wish to implement (I am happy > with sockets, but others may desire other things). > > My reasoning to this is that my ideas have not involved the low level > graphical object types (figure, axes, surface, etc.) in Octave actually doing > anything apart from feeding user commands to the language plugin. The > language plugin would create the outgoing communication stream to the > visualisation application. Thus the bulk of the work is done by the external > application, and the graphical objects in Octave are merely interface stubs > that have no functionality (and in fact no data other than an ID) in > themselves. > > I would propose that interested parties begin an ongoing discussion on the > octave-graphics mailing list. If that means just you (Ole) and me, then so be > it. What would be wasteful were if we all continue to work without any common > understanding and then end up with different incompatible systems. > > Nic > > PS How is OPlot++ coming along? > > Le Dimanche 9 Novembre 2003 02:55, Ole Jacob Hagen a écrit : > > Any comments? > > > > > > Cheers, > > > > Ole J. >