Re: Oplot

If you have get/set implemented in a compatible way, by all means have 
somebody put them into octave-forge.

Similarly, all high-level functions like plot which should work 
identically no matter what the underlying graphics engine actually 
displays it.  Presumably they should translate the various options into 
the underlying get/set calls from handles returned by 
figure/axes/line/patch primitives.  An interface to
gnuplot can be implemented on top of that if anyone is so inclined.

On the other end, I would like to see the opengl functions isolated 
into separate calls with a minimal interface.  That is, an opengl 
context and raw arrays, and nothing specific to qt or gtk or whatever.

- Paul

On Nov 30, 2004, at 11:37 AM, Shai Ayal wrote:

> Ole,
>
> looking through the code in oplot/props/octave I see you have already 
> done what I have proposed in my previous email: mainly you have 
> implemented a minimal set of "core functions" -- set, get, etc... on 
> top of these you could in theory used my plot.m file instead of the 
> oplot.cc you use now.
>
> All this without going into elaborate explanations of callbacks 
> etc..., using m-files only.
>
> 	Shai
>
> Ole Jacob Hagen wrote:
>> Hi, Shai.
>> Yes, thanks to Shai, we have contour-plot in Oplot. ;-)
>> Have you looked at Props-source? And it's usage in the following 
>> classes :
>> OpFigureManager (Props::Root), OpFigureWindow (Props::Figure), 
>> OpAxesObject (Props::Axes), OpLineObject (Props::Line)? These four 
>> classes represents each a graphics object. And the virtual method 
>> property_changed is run, when a property has changed. This is due to 
>> a callback setup.
>> Actually, Prop-package is the heart in Oplot.
>> Root::instance().setRootCallbackInterface(this) inside ctor of 
>> OpFigureManager says that every callbacks regarding a property change 
>> in root-object is controlled to OpFigureManager.
>> In Octave: f = figure; will make this code run.
>> % snip of code %
>>> int OpFigureManager::new_figure( Figure* fig) {
>>>     OpFigureWindow* fw = new OpFigureWindow(fig, this);
>>>     fig->setCallbackInterface(fw);
>>>     this->addFigureWindow(fw, (int) fig->getHandle());
>>>     return 0;
>>> }
>> % end snip of code %
>> We create a new OpFigureWindows, and connects the Figure-callbacks to 
>> our newly created OpFigureWindow instance.  And we adds this figure 
>> window into a QPtrList.
>> When we create a line-object, by using h = plot(x,y) will run this 
>> code, since Line is a child of Axes
>> % snip of code %
>>> int OpAxesObject::new_child( Object* p,  Object* child) {
>>>      if((*child->get_string("Type") == "Line")) {
>>>         Line* line = static_cast<Line*>(child);
>>>         OpLineObject *lineobject = new OpLineObject(line, this);
>>>         line->setCallbackInterface(lineobject);
>>>             }
>>>  return 0;
>>> }
>>>
>> % end snip of code %
>> We create a OpLineObject and connects the callbacks of line-object 
>> into our OpLineObject.
>> So every change in a line-object in octave, e.g set(h, 'color',[0 1 
>> 0]) will make property_change inside OpLineObject be executed.
>> Could this be used by visualisation applications, if we convience 
>> Paul Kienzle to merge it into octave-forge?
>> This means that Octave has a common library for handling graphics 
>> objects, which can be used by many visualisation applications. The 
>> visualisation application will be responsible of communication 
>> interface to and from Octave. And Props will be a layer that handles 
>> graphics objects, and properties within the visualisation 
>> application. Octave doesn't need duplicate copies of datas.
>> Can I test the possibility to use Props inside OctPlot? Or will you 
>> Shai?
>> It would be interesting if it's feasible. ;-) It should be.
>> The code needs some refactoring, I guess. But refactoring is good, 
>> not evil.
>> If more people are interested in Props-package and how it really 
>> works, then send me an email, and I will send you some more 
>> documentation about it.
>> Cheers,
>> Ole J.
>