From graphics-request at octave dot org Tue Dec 21 02:37:57 2004 Subject: Re: Octave GUI API: Proposal. From: Ole Jacob Hagen To: N Smethurst CC: graphics at octave dot org Date: Tue, 21 Dec 2004 09:35:45 +0100 Hi, Nick. It's nice to see you on the mailinglist again. ;-) How are you? Well, octave-gtk project is making a Octave GUI now, but I hope this will be a layer that can be used by any visualisation/gui application to octave. There is a guy who is making a Qt GUI gui to Octave, but I believe this work is based on kOctave. I've seen any code, though.... The octave gui and graphics object layer must be independant from any GUI widgets, but can be used as an common library for any visualisation/GUI application to Octave. If Props-package in Oplot were refactored, then it could be within Octave. Maybe Paul would be interested in adding a refactored Props package into octave-forge? We have had a similar discussion earlier, but it's a very interesting discussion. How to make a GUI independant GUI layer to Octave, and still be able to make both visualisation and buttons/sliders, and so on? 1. First we need a graphics object handler library as base, right? This library could be a props-related library. 2. This library should be used by any visualisation applications, GUI frontends if the GUI frontends handles graphics objects as well. 3. Communication protocol between Octave and GUI frontend/visualisation application can be decided by a entry in .octaverc? 4. Name of visualisation application could also be an entry inside .octaverc. 5. m-files such as set,get, findobj, line, surf, patch and all the other related visualisation m-files is high level m-files for manipulating graphics objects. 6. Octave will then be responsible to send data to a predermined vis.app by reading .octaverc Entry could be such as: VIS_APP=acoolvisapplicaton, VIS_PROT = pipe But this strategy might break a GUI frontend.....In Oplot we are just using Props as a common library for handling graphics objects, and is working pretty well. Oplot is not using configuration entries in Octave. But to use Oplot you need to call oplotcom_setup; before you start using Oplot. This is done once. And can be added into ~/.octaverc, where it should be. I don't think Octave should handle graphics objects at all, since each visualisation application should be responsible for this. But this is my opinion. To octave-gtk people: Are you also making a graphics object handler as well as a GUI frontend to Octave? Cheers, Ole J. How is your development of KV going? As you pointed out, I am to lacking of time right now. N Smethurst wrote: >Hello all. > >In an effort to come back from the dead and reintroduce myself into the Octave >community, I wish to offer my help in the design of the Octave GUI layer. > >I have, of course, a keen interest; it is something Ole and I have talked >about in the past and intended to start. > >My current comments are: > >1. The base GUI layer must not depend on any libraries other than those which >Octave already depends. > >2. I would suggest a simple plugin system for implementing specific GUI >systems, where the plugin library could be specified at Octave startup. > >3. The base GUI layer should take the form of handle graphics, with higher >functionality written as .m files. > >What I lack currently is: > >1/ lots of time > >- this is something I need to sort out myself > >2/ a deep understanding of the class hierarchy in Octave. > >- I ask therefore if someone could write or point us to a full explanation of >the class hierarchy, and how to create custom types in Octave. The last time >I looked (I admit this was some time ago) there was limited documentation. > >On Friday 17 Dec 2004 10:42, Ole Jacob Hagen wrote: > > >>We are also planning to make a octave-internal graphics object handler, >>but have made a Props package to Oplot, which is an external library >>that comes with Oplot. This package is using callbacks, when a property >>has changed. >> >> > >Ole: could the Props package form the base of a internal Octave GUI layer? > >Regards to all and I hope we can implement a simple but effective GUI layer in >Octave soon. > >Nick > > > >