From octave-graphics-request at bevo dot che dot wisc dot edu Thu Mar 11 10:43:06 1999 Subject: Re: Comments on GUI and plotting library From: Jonathan King To: octave-graphics at bevo dot che dot wisc dot edu Date: Thu, 11 Mar 1999 10:42:34 -0600 (CST) On Thu, 11 Mar 1999, John W. Eaton wrote: > > On 9-Mar-1999, Rafael Laboissiere wrote: > > | 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. > > I don't know if anyone is working on this. I haven't done it myself. > > Several people have pointed out wxWindows. I've looked at the web > page for it and it seems like the most likely candidate to me at this > point. I've rummaged around a bit, too. I would guess that the only other viable contenders out there would be Tk without Tcl, and Gtk(--). For Tk without Tcl, the perltk stuff tried to wrench Tk away from it's tclishness (heh) with at least some success, and they've claimed that you should be able to rebind other languages to their ptk library. The big advantages of Tk are that it is reasonably well-known, unlikely to disappear anytime soon, multi-platform, mature, has an excellent canvas widget (see below), and is known to bind well to scripting-type languages. I *think* the license should be compatible with Octave. The disadvantages are that it isn't GPL, and it has some dorky features (but what doesn't?). Gtk is another toolkit that looks interesting, and it has a C++ wrapper called Gtk(--). It enjoys bindings to lots of scripting languages as well. Unfortunately, its canvas widget is apparently part of gnomelib rather than Gtk, which is a bit weird. It's also not as mature as Tk or other established tookits. wxWindows is an ambitious attempt to go cross-platform, multi-toolkit, and is in C++. I don't know about its canvas stuff, and the docs were completely huge, so I haven't looked at them much. The only problems I see with wxWindows are that I'm not sure how easy it is to bind it to scripting-type languages, and I'm not sure how "ready" it is in terms of its maturity. Are there any other big projects out there that use it? > It is distributed under terms that are compatible with the > GPL and it provides the possibility for working under Windows NT/95 > with a Windows look-and-feel. I don't personally care very much about > that, but some people might and it seems like a good idea to leave > that possibility open. For better or for worse, I think its very important that any GUI Octave uses also work under NT/98. After all, people running these are probably the folks who would most want Octave to have a GUI. > Since it already works with several different > toolkits, perhaps we don't need to worry about defining our own > generic interface on top of wxWindows? Maybe we can just trust that > it is already generic enough? (It would be useful if someone who has > more experience with GUI toolkits could comment on this.) I don't have a lot of experience with GUI toolkits, but one thing I can say is that the Tk approach (i.e., a rather high-level toolkit) is potentially much easier to get working from a scripting language than something that has hundreds of routines available. But gtk apparently has reasonably abstract bindings to scripting languages, too. I don't know about wxWindows; the wxPython code I saw yesterday seems to suggest that it's pitched at a somewhat lower level of abstraction. Another very desirable thing if you want to do interactive plots and "handle" like graphics is a good Canvas widget. Tk has one; gtk might have one if you roll gnome into the mix, and I'm not sure about wxWindows. The Tk canvas widget is great because you can embed almost anything in it from images to text to menubars, and, for better or for worse, it's easy to see how you could implement satanic handle graphics for it. > | 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. Unfortunately, I have to say that I think providing the possibility of strict compatibility with Matlab is necessary. Many of the people I know who *would* use (and maybe even help work on) Octave only fail to do so because of its perceived weakness in the areas of graphics and GUIs. But you could enable this with Yet Another Octave Switch, perhaps --luser-interface-mode or something... > As I've said before, if there is a better way of doing things, I think > we should use the better way with the idea of being able to provide a > compatibility layer. For example, would > > gui_object.background_color = "blue"; > gui_object.geometry = "..."; > redisplay (gui_object); > > or something similar make more sense than set and get? Well, almost anything would make more sense that set and get, unless you need luser-interface-mode. One of life's great ironies was that Perl/Tk is (in my opinion) a cleaner way to use Tk than Tcl/Tk, because they blew away the "set" nonsense and provided a better syntax for the "endless list of options" problem that Tk sometimes requires. (And also because Perl provides real closures, which makes constructing call-backs a lot nicer than the Tcl/Tk way.) > It would seem > to be easy to write get and set in terms of this kind of data > structure, but I don't know for sure, since I've never really used the > Matlab GUI stuff and I don't have much experience programming with GUI > toolkits. The matlab GUI stuff, like the handle graphics stuff, is stupendous for it's lack of use of any reasonable structure. I could never figure out why they would add structures to the Matlab 5 language, and then *not* use them for graphics and guis. It's just bizarre. On the other hand, I think its possible to mechanically translate: uicontrol('Style', 'pushbutton, ... 'String', 'Plot', ... 'Callback', 'plot(x,y)', ... 'Units', 'point', ... 'Position', '[50 65 75 35]) to mypush = pushbutton('Plot'); mypush.Callback = "plot(x,y)"; mypush.Units = "points"; mypush.Position = [50 65 75 35]; or something like that. > | 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. > > I think it would be nice if we had a widget that could be used as part > of the GUI toolkit we choose. Then the graphics widget could be used > as part of the GUI too. Perhaps some existing graphics library (the > GNU one, or plplot, or gnuplot) could be adapted? Well, using *some* existing graphics library has to be better than rolling your own. :-) But combining multiple graphics and gui objects just screams "canvas widget" to me. You can render the graphic object using the library, and plop the bitmap into a window with a cute "Figure 1" label and the menubar that people love and expect. With only a little more work you can even handle the button clicks on the graphics and stuff. More importantly, you can combine an image with a plot (or multiple plots) trivially without relying on gnuplot multiplot or other weirdness. So I guess to summarize my input on this, it might also be worth looking at the ptk library and its capabilities since it was designed to be portable between languages, is tcl-free, is a remarkably good match for the current Matlab handle graphics/GUI stuff, and provides a canvas that you can add new types to if you need to (or you can render things to bitmaps and display them. My hunch is that this is the easiest route to take, although I could well be wrong. Good graphics and clean GUIs are hard. jking