From octave-graphics-request at bevo dot che dot wisc dot edu Wed Nov 12 04:22:22 2003 Subject: Re: Octave graphical objects (was: Handle Graphics..) From: N Smethurst To: Ole Jacob Hagen , octave-graphics@bevo.che.wisc.edu Date: Wed, 12 Nov 2003 11:24:07 +0100 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