From octave-graphics-request at bevo dot che dot wisc dot edu Tue Mar 9 15:48:05 1999 Subject: Comments on GUI and plotting library From: Rafael Laboissiere To: octave-graphics at bevo dot che dot wisc dot edu Date: 09 Mar 1999 22:48:00 +0100 I joined this list some days ago. I went through the few messages sent to the list since its creation (thanks John!) and had some thoughts on all this stuff. Apparently, there are some quite separate problems that we are facing now, although they are interrelated: 1) Definition of a user level interface, probably in the form of a C++ class, for both the plotting calls and the GUI objects. Comment: I agree with JWE that this should be as toolkit-independent as possible. Question: is somebody doing this? If there is a written (even rough) design around, I would gladly take a look. 2) Definition of the interface at the Octave language level. Question: are we going towards Handle Graphics (TM) or will we try to keep compatibility with the gnuplot syntax? I did a lot of graphical Matlab programming in the past and I really think that Handle Graphics is not a good thing. If strict compatibility with Matlab matters, there will be then no choice. 3) Finding a adequate plotting engine. Comment: I say "finding ", because I am sure we are going to reinvent the wheel. Question: what are we looking for exactly? A plotting library (a la plplot or pgplot) callable from C++ or a pipe-communicating program (a la gnuplot)? I think that a plotting library would be more appropriate for our goals, but I may be wrong. Comments on PLplot (to answer Matthew's question): I know this library quite well, because I am the official maintainer of the plplot and octave-plplot packages for the Debian GNU/Linux distribution. PLplot produces nice graphics, has a well designed API, besides doing 2d and 3d very well (they look better than gnuplot's). There are many drivers implemented for PLplot, including PostScript and X. The driver interface is also well designed and it looks quite straightforward to add a new driver. I started coding a driver for Gtk/Gdk last year, but had to stop before December by lack of time. The idea was to have a Gtk widget that would contain the graphical rendering and would respond to mouse events. This widget could be easily integrated in a GUI. This project is though too Gtk-centric, and is maybe not what we are looking for. I see two drawbacks with PLplot: first, the font support is quite bad. Indeed, the characters are built with a bunch of lines. This was done because many drivers in PLplot do not have a clue about what is a PostScript font (Tek, for instance). The second drawback, is that PLplot is not actively supported nowadays. Snapshots come every six months and development is very slow. Fortunately, PLplot is GPL'ed, so there would be no problem in forking/continuing the project, if we really want it. 4) Implementation with specific toolkits. Rant: I have a penchant for Gtk+, but this is a personal thing (may even change in the future). Matthew Valenta mentioned wxWindows, which IIRC is more a wrapper than a real toolkit. In the past (back to the start of this mailing list) Tcl/Tk was much discussed, and seemed to be the natural choice. To be frank, I do not really care. I think that it will be even better if people here will try different toolkits. In this way, we will be able to factor out the common denominator for the interface, as well as to bring useful ideas together. Matthew Valenta and JWE mentioned interprocess communication via sockets and CORBA. Is this a real proposal? Do you have anything more concrete on that? -- 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