Octave 3.0 plotting API/interface

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Octave 3.0 plotting API/interface

N Smethurst
Hello everyone..

Le Samedi 22 Février 2003 14:43, Per Persson a écrit :
> I'd really like to see some kind of plotting API/abstract
> class/interface whatever that sits between octave and any present
> and/or future plotting solution.
> I know this has been dicussed before, but mostly in the context of GUIs
> and stuff. Certainly, it would be nice to have a similar solution for
> all kinds of fancy widgets but the plotting part could probably be done
> separately from buttons and sliders etc.

Although I'm new to the mailing list, I have been following the progress of
Octave for some years. I notice that there has been another dialog recently
on the subject of the future direction for an Octave plotting/visualization/
gui interface. I am currently in the middle of the design stage of a general
visualization plug-in program (using kde/vtk) which is intended to be used
in conjunction with numerical software. My interests lie mainly in the areas
of audio, acoustics, signal and image processing, so my own development
ideas will tend to be very general.

Before you all sign heavily and say "oh no, here's another stranger claiming
to be developing the visualization solution that's going to be the one to
use," I'd like to express one or two thoughts. Firstly, I wouldn't at all be
surprised if you are thinking that. There seems to have been so many people
who have come along with a similar story, only to disappear again after
pounding out some code that does half a job and then getting bored. Why
should I be any different?

Hence, secondly, I'm not going to begin suggesting that my currently
not-ready-for-use software is necesarily going to reach a stage where it is
of great use to anyone. Whether it turns out to be useful or not will only
be known in the future, so such talk is irrelevant in the present.

My interest here is to try to provoke an interesting, constructive and
hopefully fruitful discussion on the subjet of a common communication method
between Octave and plotting/visualization/gui software in general. At best,
such a method would be graphics package independant, allowing the user to
easily drop in whatever package she desires, knowing that all her old
scripts and functions will continue to run correctly with the new package
(assuming it conforms to the Octave specification). Any additional
functionality that a particular graphical package may provide could be
integrated with separate .oct files that belong to the package and have no
bearing on the core functionality of the Octave plotting/gui system.

It is clear that there are a number of independant projects in existence
that do interface or plan on interfacing with Octave, mine included. I would
like to suggest the possiblility that everyone who has an interest in the
development of a common Octave plotting/visualization/gui interface begin a
constructive and ongoing discussion on the octave-graphics mailing list.

Such a discussion and the hopefully subsequent interface development will
transcend any complication and potentially wasted effort if/when people
disappear after providing useful input. I have grand plans but am honest
enough to acknowledge the uncertainty of how far these plans will get.
However, if I or anyone else, before potentially disappearing (or not), can
be productive in the development of a common interface, the only possible
result of this will be very positive for the community.

Does anyone find this idea appealling?

Regards and hope to hear your thoughts on this subject.

Nicholas Smethurst


Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0 plotting API/interface

Herman Bruyninckx-3
On Fri, 28 Feb 2003, N Smethurst wrote:

[...]
> My interest here is to try to provoke an interesting, constructive and
> hopefully fruitful discussion on the subjet of a common communication method
> between Octave and plotting/visualization/gui software in general. At best,
> such a method would be graphics package independant, allowing the user to
> easily drop in whatever package she desires, knowing that all her old
> scripts and functions will continue to run correctly with the new package
> (assuming it conforms to the Octave specification).
[...]
> Does anyone find this idea appealling?

I do :-) (My personal motivation is to have a plotting/visualisation
interface not to a numerical program such as Octave, but to a robot
control system. The requirements remain exactly the same though.)

My personal opinion: if you really want to make a generic plotting
interface, look at how to specify a CORBA plotting component. This would
ensure complete independence of whatever numerical processing software.
Aiming high and working towards something that might eventually be
strong enough to be accepted as an OMG/CORBA standard is the only way to
go: all other efforts will remain tied to one particular application.

So, I guess one needs specs for:
- data sets:
  + in batch, or streaming in one by one.
  + identification of what each part of the data means, including meta
    information such as physical units, time synchronisation, etc.
- generic plotting functionalities
- a "component interface" of the data generating application as well as
  the data visualisation application. (And maybe the application
  programming interface is a third component.)
  "Component interface" is well-defined in CORBA, which differentiates
  between several types, according to whether or not they have a
  "persistent state" (= come up after reboot in the same state as before)
  or not, and an identity (= applications know the name of the component
  they ask services from) or not.
- name serving (this is also part of the CORBA spec).
- "funtionality browsing": each component in the system (numerical
  processing, visualisation, programming, ...) can answer calls asking
  about the services it can provide.

Depending on your taste, you could call this design octave.NET :-)

Herman Bruyninckx

--
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480


Reply | Threaded
Open this post in threaded view
|

Re: Re: Octave 3.0 plotting API/interface

N Smethurst-2
Le Vendredi 28 Février 2003 21:01, Herman Bruyninckx a écrit :
> My personal opinion: if you really want to make a generic plotting
> interface, look at how to specify a CORBA plotting component.

Well, I was thinking more along the lines of defining a protocol independant
interface in Octave, with something like a plugin system for specific types
of communication. That way, if someone specifically wants to use Octave with
CORBA or DCOP or whatever, it would just be a matter of writing the plugin
and setting the relevant Octave environment variable in the startup. After
the basic interface is in place (along with one or two basic plugins such as
pipes and sockets), the burden of coding up other protocols would be on those
who have a specific need for them.

With this approach, what needs to be done initially is an evaluation of the
current system and the definition of a new or evolved one at the (Octave)
user end. This would not initially involve any specific protocols.

Nick


Reply | Threaded
Open this post in threaded view
|

Re: Re: Octave 3.0 plotting API/interface

N Smethurst
In reply to this post by N Smethurst
Le Vendredi 28 Février 2003 21:01, Herman Bruyninckx a écrit :
> My personal opinion: if you really want to make a generic plotting
> interface, look at how to specify a CORBA plotting component.

Well, I was thinking more along the lines of defining a protocol independant
interface in Octave, with something like a plugin system for specific types
of communication. That way, if someone specifically wants to use Octave
with CORBA or DCOP or whatever, it would just be a matter of writing the
plugin and setting the relevant Octave environment variable in the startup.
After the basic interface is in place (along with one or two basic plugins
such as pipes and sockets), the burden of coding up other protocols would
be on those who have a specific need for them.

With this approach, what needs to be done initially is an evaluation of the
current system and the definition of a new or evolved one at the (Octave)
user end. This would not initially involve any specific protocols.

Nick

PS sorry, this may possibly have been sent twice.