From octave-graphics-request at bevo dot che dot wisc dot edu Wed Nov 12 15:04:13 2003 Subject: Re: Octave graphical objects (was: Handle Graphics..) From: Ole Jacob Hagen To: N Smethurst Cc: octave-graphics at bevo dot che dot wisc dot edu, pkienzle , jwe Date: Wed, 12 Nov 2003 21:58:34 +0100 Hi. So you are thinking about letting the visualiser have handle graphics objects, and Octave can collect handle graphics objects by running gca_handle = get(gca)? So there will be no handle graphics inside Octave, except when user are running the get? You can reach homepage of Nimrod Mesika on this link: http://www.geocities.com/rodd_27/octave.html Download his source, and you'll get surprised over his structure of handle graphics. This can be used, I guess. How are you transferring data's from Octave to kvisualiser and back to Octave? Have you defined a protocol like this one (which means that you are sending all h-g objects at the same time ): STX, HEADER, property(1), property(2), ......., property(N-1), property(N)* ? example of usage: example 1: STX, linepropety,Color, EraseMode, LineStyle, LineWidth, Marker, MarkerEdgeColor, MarkerFaceColor, MarkerSize, XData, YData, ZData* ? example 2: STX, gca, AmbientLightColor, Box, CameraPosition, CameraPositionMode, ......, XTickLabels, XTickLabelMode, XTickMode, YAxisLocation* Messages in example 1 can be very large, since XData, YData, ZData can be pretty large. This was the line_handle = line(x,y), but there is also a surf_handle = surf(), which is very large, indeed. I hope communication protocol between Octave and visualisation-applications is not based on the bad examples I mentioned above. Reason; It is not very flexible, and is a waste of time and bandwidth, can be very time consuming If an error occurs, where did it happen? Bad generation of message, bad checksum Message can be very large. You are using some time, so construct message, and parse it. I have a communication protocol, which just sends updates, where you can flush/refresh your visualisation. I can make a overview of the communication protocol between Octave and Oplot++, but the main idea is to send only one data-object at time. In communication protocol between Octave and Oplot++, I have defined 3 basic messages: 1. A information message, that informs external visualisation applications that either, gca, gcf, root, h=plot(x,y) are to be configured. 2. A set-message, which are setting/changing a PropertyValue of a PropertyName which are inside visualisation application. 3. A get-message, which are getting a PropertyValue of a PropertyName, which are used by the visualisation application. I believe we are getting into some ideas on how octave handle graphics should appear to user, and how it should be implemented? With this layout, it doesn't matter if Matlab is extending their handle graphics or Octave wants to extend it. The base protocol is already there. Any comments? Paul? John? Cheers, Ole J. On Wed, 12 Nov 2003 11:24:07 +0100 N Smethurst wrote: > Le Mercredi 12 Novembre 2003 02:21, Ole Jacob Hagen a écrit : > > > I cannot see much point in duplicating data between Octave and the > > > vis-app. The Octave end of things doesn't really do anything with the > > > information unless the user requests it with an access instruction, and > > > that is something that happens infrequently (relative to other > > > processes). > > > > As you pointed out, > > This doesn't matter at all, since two "copies" of visualisaton data will be > > used anyway, I guess. > > Well I would say that there is a single copy of visualisation data. For > example, if you issue the following commands in Matlab: > > x = [0 1]; > y = [2 3]; > h = line(x,y) > clear x y > > then the line data is still in the line object and can be obtained: > > get(h, 'XData') > get(h, 'YData') > > The line is not dependant on the variables that defined it. In KV, the line > data is store in KV's memory. Octave has nothing to do with it (and why > should it - Octave is not responsible for the visualisation, KV is). This is > why I am interested that the low level graphical objects in Octave are merely > comms stubs that store nothing but an ID and callback names. > > > Yes, I did take a look at your web-page, and looked at your header-file. > > Have you been inspired by Nimrod's work? > > It was pretty the same thing, you've written down. > > I'm not familiar with this guy.. do you have a web link to this work? If him > and me are saying similar things independantly, that can only be a good > thing! Is he subscribed to this mailing list? > > > What ideas do you have in developing a GUI-frontend for Octave? > > Considering the finite time one has available, I'd rather concentrate on the > vis-app and plotting interface first, and then a QT GUI can come later if > noone else has already started working on it. > > > Do you have complete source code of kvisualiser? > > Would you mind, if you sent me a copy, please? > > This is the current situation with KV: > > At the moment, I am completing the template code for direct usage of low level > VTK objects via the objet browser. This is more orientated to people that > wish to work directly with VTK, but will eventually be usable from apps like > Octave as well for advanced visualisation. > > I now have a KDE CVS account, so once that is done, KV's source code will be > placed into kdenonbeta. This will not include the cartesian axes code, since > I want to rewrite it first. Thus this initial code base will be more > interesting to VTK users rather than Octave ones. > > In the meantime, free.fr finally let me upload some API documentation this > morning, so you can browse or download it now. > > > Since handle graphics objects should be internal of Octave, > > we will require a good design so it can be merged directly > > into GUI-frontend, or what is your opinion on this? > > My opinion is that graphical objects are independant of any GUI frontend. > > > Are kvisualiser storing other data than visualisation-datas, such as X, Y, > > and Z? Oplot++ is storing this data as well, and additional there are > > linewidt, linestyle and other tings, but these datas are neccessary for > > visualize at all. > > Every graphical object property is stored in KV, for example: > > http://kvisualiser.free.fr/dev/api/classkvAxesProperty.html > > XML from the to-be-written language plugin in Octave is sent to KV and is > dealt with in the domIn() methods of these property stucts. The structs also > contain default values used during object creation. > > > When we have created and sent handle graphics datas to the > > visualisation-application, should we destroy them in Octave? I guess not. > > And thereby getted from visualisation application? > > Or should we keep a copy inside Octave, and send these datas to > > visualisation application? Should we let visualisation-application change > > these values? > > Besides, visualisation-application needs information about appearance of > > objects (Curves, surface, labels and so on) to visualise. We don't need to > > store them inside our application, but they are available, if we want to > > return them back to Octave. > > > > ... > > > > Octave should be able to manipulate h-g objects, and sent it to > > visualisation application. Should we say that only Octave can manipulate > > and change h-g objects? What about when a user, wish to change h-g objects > > inside of v-a (visualisation application)? Should we disable this > > functionality for now? > > In the KV model, Octave doesn't have a copy in the first place. > > > We also need a h-g browser inside our v-a's, don't we? > > a big yes here! > > Nic >