From graphics-request at octave dot org Wed Dec 1 01:44:35 2004 Subject: Re: Oplot From: Ole Jacob Hagen To: Shai Ayal , graphics@octave.org CC: Paul Kienzle , jwe@octave.org Date: Wed, 01 Dec 2004 08:40:09 +0100 Hi, Shai. I hope you are not suggesting that octave should handle "graphics properties" internally? I would not in particular not agree on this strategy, since I think that graphics properties should be handled by each visualisation application. What GNU Octave should provide is a common "graphics object properties" that every visualisation application can use (and abuse). This will strengthen GNU Octave flexibility in becoming the most configurable language for numerical computations AND visualisations. This is the main idea here. Let say we include a graphics property library into octaveforge, that a visualisation application can use. Then we should also say that octave provides the library, but each visualisation application must handle the a duplex comm-interface, protocol, additionally they should handle how the visual representation should appear as well. In Oplot we have implemented in almost this fashion. We have made an external "graphics property"-package named Props, while Oplot handles the duplex communication, + there is some comm-source in src/octave/oplotcom.cc from octave-side. Octave is acting as a "server" while Oplot is a client. We have also provided a set of m-files, as you mentioned Shai. Our m-files are: oset.m, oget.m, ogca.m, ogcf.m, osubplot.m, otext.m, olabel.m, otitle.m, ohold.m, oishold.m, oline.m, ofigure.m, oimage.m, oaxes.m, oaxis.m, ocountour.m. osurf.m, omesh.m and opatch.m is to be made in a later stage of development. The dispatch routine found in octaveforge, helps us in making "aliases" to these o-prefixed m-files, so they can be ran using, set, get, gca, gcf and so on. We believe that Props can be used, but personally I think we should refactor the code a bit. But it should be quite ready, really. Another thing is that the other higher level functions, such as e.g plot.m, gca.m, figure.m, they can actually be a part of an graphics property package, iff plot.m is using line-object. Since plot.m is found in octave-src/scripts/plot, it has to be either overloaded or the path to our vis.app's m-files should appear before the path to octave's own plot.m command. This means some fiddling with DEFAULT_LOADPATH, but this strategy is used in grace-package found in octave-forge. Any comments? Cheers, Ole J.