From octave-graphics-request at bevo dot che dot wisc dot edu Wed Nov 12 19:31:02 2003 Subject: Re: Octave graphical objects From: Ole Jacob Hagen To: N Smethurst Cc: octave-graphics at bevo dot che dot wisc dot edu, jwe , pkienzle Date: Thu, 13 Nov 2003 02:25:20 +0100 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. This will mean that both your structure and Nimrod's structure is the right one. Octave will then have "driver" for handle graphics objects, which can be altered and viewed by using set and get. If we take the best of both yours, and Nimrods implementation, we'll get there. I guess your ObjectID is just a identification of figure-plot? Can be interpreted as handle-value, or is it strictly a ID of a graph from the visualisation application? Will this value be the same as the figure number, which Matlab generates? We will have to decide, whether we shall have handle graphics routines included in Octave Core, or at octave.sf.net. For starters, I guess we have to include it at sourceforge, don't you think? >From my point of view a user should be able to: 1. Change graphics objects both from Octave and/or visualisation application. 2. If a change is done within visualisation application, then advanced numerical processing should be avoided. Octave should handle processing of datas, which are to be displayed inside visualiser, yes. But if a user wants to change some attributes, he could choose whether he likes to chan > There would be no reason why we couldn't implement dynamically loaded > graphical object types as well as dynamically loaded language and comms. My > object types would be empty stubs apart from an object ID and callback names, > whilst your objects would have functionality and OPlot would be responsible > for less of the work. Well, I would prefer, that we have a common handler of graphic objects, inside Octave. Proposed structure (Hope it appears correctly): Object | -------------------------------------------- | | | | | | | Axes Text Line Patch Light Figure Image cont'd Object | ---------------------------------- | | | | UiControl Uimenu Root Surface One suggestion for Transport layer. Will not be trivial to solve, I guess. Tranport (abstract class) | ------------- virtual inheritance? | | PipeIO SocketIO All subclasses of Object has setp, and getp-methods, which is an interface to the set/get functions of handle graphics. Inside Object-class, we have our DEFUN_DLD's where handle graphics functions set/get appears. All subclasses of Object will also require a update-scheme, where linking to external applications, data-transfer should be executed. This idea is good, I think. But we still got a huge problem. How to link to another applications? Should we be able to change visualisation application run-time? Or should this be decided by configure? If configure-decision is made, then we will need: --with-visapp= and --with-transport= Then the transport-class can be defined by preprocessor-directives. If we will be able to choose run-time, we will need a more clever strategy. Maybe it the transport-layer should read a configuration-file? Then Tranport class will be one and only. And it will read a configuration file, e.g xml, or rc? Which is placed in $(OCT_INSTALLDIR)/share/octave/$(OCT_VER)/m/handle_graphics/transport.? Example of tranport.rc could be: VIS_APP= TRANSPORT_TYPE= TRANSPORT_METHOD= Where one, means that paramters, are sent or received one by one e.g setProperty(gca, 'XGrid', 'on')/getProperty(gca, 'XGrid') all means that whole gca-properties are sent or received e.g setProperties(gca) / getProperties(gca) This means that the Tranport class will be defined once (, and called by Object-class?), and just sending data's as decided by configuration-file. Could this be feasible? This will require that handle graphics routines are maintained by both of us. It might be a advantage to have it included at sourceforge-stite of Octave, or? Shall I make a skeleton of this structure? Is it good enough? Comments? How hard should we do this? This is pretty much what Nick wants to do, I guess? > Taking that train of though even farther, if you wanted you could even > integrate everything from the graphical objects right up to the comms output > if we had a common API for the dynamically loadable graphical object types. Shouldn't we strive for this? Cheers, Ole J.