From octave-graphics-request at bevo dot che dot wisc dot edu Tue Nov 11 19:26:48 2003 Subject: Re: Octave graphical objects (was: Handle Graphics implementation in Octave.) From: Ole Jacob Hagen To: octave-graphics at bevo dot che dot wisc dot edu Cc: Nick Smethurst Date: Wed, 12 Nov 2003 02:21:17 +0100 Hi. On Tue, 11 Nov 2003 15:34:42 +0100 N Smethurst wrote: > > Le Mardi 11 Novembre 2003 09:47, Ole Jacob Hagen a écrit : > > 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. > > This is an interesting point. Did you take a look at my page at > http://kvisualiser.free.fr/dev/octavegraphics.html > > specifically the second part about graphical object types? The idea goes like > this.. > > 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. 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. We are actually doing the same thing now, so I suggest we start collaberate, as soon as possible. You've said it for several months ago...;-) What ideas do you have in developing a GUI-frontend for Octave? Please take a look at: http://www.octave.org/mailing-lists/octave-maintainers/2003/341 I've suggested some future directions, which involves GUI-frontend developed in Qt, since Qt are more portable than kde is. Since we both are developing Qt/KDE applications, this wouldn't be any problems, would it? We are really doing the same thing, really. This is a waste of our time...reinventing the wheel, is for bad developers only. And we two are really doing it multiple times....;-) Do you have complete source code of kvisualiser? Would you mind, if you sent me a copy, please? Code of Oplot++ is available from CVS-server at http://sourceforge.net/projects/oplot If we don't make a GUI-frontend right now, we should still keep this in mind, so we don't make any misjudgements, when it comes to developing, and making of a flexible handle graphics. 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? We should also strive for possibilities to use either gnuplot, kvisualiser, oplot, qmatplot or knewplot. Since these are the five visualisation-applic's that are available today. Some in development, but progress i good. Stupid question(s): 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. Coin requires these data-objects, and default values are chosen for me, if I don't manipulate them. > Octave would not be responsible for generating any intermediate visualisation > data of the low level graphical object types, since this is the job of the > visualisation application. Yes, octave just sends data to visualisaton applications, where visualisation applic's are only handling the visualisation. 1. Make data (both plot, surf and handle and so on) 2. Send data to visualiser from Octave 3. Visualise 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. Matlab works like this; It is possible to change properties directly from GUI. Let us make a 2D plot of a sine-curve. h = plot(x,y); h_gca = get(gca) Take a look at h_gca. h_gca wouldn't be updated, if we turn on grid in both x and y directions from our figure. This means that the figure is actually keeping a modified version, which is not readby matlab command window, until we explicit calls new_gca = get(gca). Now new_gca contains XGrid = on and YGrid = on. I guess that we should do the same. Comments? 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? We also need a h-g browser inside our v-a's, don't we? Cheers, Ole J.