From octave-graphics-request at bevo dot che dot wisc dot edu Thu Nov 13 06:47:53 2003 Subject: Re: Octave graphical objects From: =?iso-8859-1?q?Ole=20Jacob=20Hagen?= To: N Smethurst , octave-graphics@bevo.che.wisc.edu Date: Thu, 13 Nov 2003 13:47:41 +0100 (CET) Hi, Nick. You mentioned two scenarios here, but I believe we are talking around eachother. I'm aware of that I said the following sentence: "Handle graphics objects, should be available inside Octave, since the handle graphics objects are a struct array. This is when you list all of them, but if you list one of them, they can be viewed as an octave_value, I guess. Therefore we should be able to list values of handle graphics objects inside Octave. Changing and getting handle graphics objects, should be available from the visualiser." I guess I need to explain it once more. What I really mean is that Visualisation-application controls handle graphics objects, but Octave can be used for both inspection and changing of handle graphics objects' values. They don't appear as global structures in memory, and doesn't occupy any memory inside Octave, however they are viewable as a struct (viewAll), or octave_value as one (ViewOne). Which means that scenario number 2 is the closest solution, so let's work on that? Scenario number 2 is also the best solution, and might also be the fastest? I don't think Octave should handle "handle graphics objects". I believe this should be left to the visualisation application to handle. In this way, we accomplishes five things: 1. A flexible interface to different visualisation applications, where all needs to use one well-defined communication protocol for receiving/transmitting messages, such as handle objects. 2. We have separated the "real handle graphics" from Octave to the visualisation application. 3. No need for typechecking inside Octave for messages received from visualisation application. A message sent from Octave to visualisation application will be set up correctly from Octave-side, inside transport-class. 4. Easy in the future to merge handle graphics code into a GUI-frontend, if this is made later on. If Gui-frontend should be handlings graphics objects as well. Which means that our work is not a waste of time. 5. Easy to maintain code. Is this good? For some basic information about creating dynamical loadable types/functions, you can look at http://octave.sourceforge.net/coda/c50.html Cheers, Ole J. Cheers, Ole J. --- N Smethurst skrev: > Le Jeudi 13 Novembre 2003 02:25, Ole Jacob Hagen a écrit : > > On Wed, 12 Nov 2003 23:18:11 +0100 > > > > N Smethurst wrote: > > > I get the impression that you wish to implement a system where > > > visualisation calculations and other processes go on inside the > low level > > > graphical objects in Octave. > > > > Handle graphics objects, should be available inside Octave, since > the > > handle graphics objects are a struct array. This is when you list > all of > > them, but if you list one of them, they can be viewed as an > octave_value, I > > guess. Therefore we should be able to list values of handle > graphics > > objects inside Octave. Changing and getting handle graphics > objects, should > > be available from the visualiser. > > Heres two scenarios: > > Scenario 1 - graphical object data stored in Octave structs. > > Setting data: > > The user calls an object via one of two methods, e.g.: > set(objHandle, 'TickDir', 'In'); > objHandle.TickDir = 'In'; > > Action: The object struct data is thus changed. The struct must then > forward > this information to the vis-app. > > Getting data: > > The user calls an object via one of two methods, e.g.: > direction = get(objHandle, 'TickDir'); > direction = objHandle.TickDir; > > Action: The object struct data is accessed to obtain the information. > What > happens then? One of two things are needed. Either 1/ the struct will > first > need to verify with the vis-app that the property has not changed; if > it has > it would need to ask the vis-app for it again; Or 2/ the vis-app has > additional code in the property setting methods that send all > modifications > back to Octave, unless it was Octave that sent the change (thus it > needs to > differentiate between properties changing via its own object browser, > and > properties changing from Octave. > > > Scenario. 2 - graphical object data stored in vis-app only, non > visualisation > properties stored in Octave graphical object stub. > > Setting data: > > The user calls an object via one of two methods, e.g.: > set(objHandle, 'TickDir', 'In'); > objHandle.TickDir = 'In'; > > Action: The graphical object forwards the information to the vis-app. > > Getting data: > > The user calls an object via one of two methods, e.g.: > direction = get(objHandle, 'TickDir'); > direction = objHandle.TickDir; > > Action: The graphical object requests the property from the vis-app. > > OR > > The property is local to Octave (i.e. callback names) and thus it is > just > returned without communication with the vis-app. > > > > Which is the simpler? In scenario 2 there is no need for any checking > code in > either of the applications since only one application is responsible > for > object properties. > > Maybe the best thing to do here if you wish to implement scenario 1 > and I wish > to implement scenario 2 is for us to work from a common template of > dynamically loadable Octave types which we can adapt for our own > needs. These > types could be chosen at Octave startup (via as you said an > environment > variable or suchlike), and thus the external behaviour of our > different > implementations would be the same to users. > > > My question is thus: is there any documentation explaining how to > create > dynamically loadable types in Octave? I didn't find much info on this > > subject, but I haven't looked for some months. > > Nick > > ______________________________________________________ Få den nye Yahoo! Messenger på http://no.messenger.yahoo.com/ Nye ikoner og bakgrunner, webkamera med superkvalitet og dobbelt så morsom