From octave-graphics-request at bevo dot che dot wisc dot edu Wed Mar 10 03:00:15 1999 Subject: Re: Comments on GUI and plotting library From: Rafael Laboissiere To: matthew joseph valenta Cc: octave-graphics at bevo dot che dot wisc dot edu Date: 10 Mar 1999 10:00:11 +0100 >>>>> "MJV" == matthew joseph valenta writes: MJV> On 9 Mar 1999, Rafael Laboissiere wrote: >> 1) Definition of a user level interface, probably in the form of a C++ >> class, for both the plotting calls and the GUI objects. >> >> 2) Definition of the interface at the Octave language level. MJV> I'm sorry. I've been up 24 hours and I don't understand the MJV> difference b/w 1 & 2. Please explain. 1 is the C++ interface and 2 is the Octave interpreter language interface (to be called from .m files). I see them as different things. For instance, there will have no compatibility constraint with 1. Of course, 2 is built on top of 1. MJV> Personally, Matlab compatibility is a must because I want to MJV> leverage Octave as a replacement for Matlab in our lab. MJV> [...] MJV> I think we should design an API as we see fit and then write MJV> wrappers to make it backwards compatible. I fully agree. MJV> I too agree that Handle Graphics is satanic. Oh, maybe you didn't MJV> say that..(and no offense to satanists...) I did not say that, but I certainly meant it ;-) MJV> Actually that sounds really useful to me. Particularly if we MJV> could make the mouse events work. In any case, I would buy MJV> embedding the plotter inside another toolkit (ala "xanim" within MJV> "aktion!") because that would keep the code seperate. How hard MJV> would this be? It seems relatively easy to write a new driver for PLplot, though I never really wrote one :-} As I mentioned before, the interface between the plotting engine and the drivers in PLplot is quite well designed. You should take a look at the sources (home page: http://emma.la.asu.edu/plplot/, but if you have a Debian box: http://www.debian.org/Packages/stable/math/plplot.html) There are several examples of drivers (from the top of my head: HPGL, linuxvga, PS, Tektronics, Tcl/Tk, XFig, X, etc.). I would be happy to discuss with you about writing a new driver. >> 4) Implementation with specific toolkits. MJV> I am also fairly ambivalent. Why don't we vote on a toolkit to MJV> focus on at the START? I vote for wxGTK. Frankly, I do not think that we should be focused on any specific toolkit from the start. The most important thing now is to define the new API for the GUI (JWE?). As I explained in my last post, it is even better if there are many people/groups working with different toolkits at the START. This will guarantee that we do not get biased in the API design. MJV> The sort of CORBA interfaces that I had in mind (GNOME's Baboon MJV> and KDE's KOM/OP) are not in place yet. I'm not even sure if MJV> they're usable yet. My knowledge of CORBA and sockets is nearly zero. Could you list the potential advantages of using CORBA interfaces instead of doing a regular implementation with libraries [e.g. (wx)Gtk and PLplot]? -- Rafael Laboissiere Institut de la Communication Parlee | Email: rafael at icp dot inpg dot fr UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael