From octave-graphics-request at bevo dot che dot wisc dot edu Thu Mar 11 17:15:55 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 17:15:35 -0600 (CST) [Hmm, could be make sure not to send stuff me and also to octave-graphics? I'm on that list now, and the duplicated email confuses me. :-)] On Thu, 11 Mar 1999, Matthew Valenta wrote: [big snip by jking] > Originally I had in mind simply using the wxWindows interface at the C++ > level, but I see why an added layer of abstraction would protect use better > from toolkit changes. > > I think we should compile a web page with that summarizes the C++ and Octave > APIs as we discuss them here. That way, we actually do something besides > discuss it! I can do that unless someone else wants to. > > > about wxWindows; the wxPython code I saw yesterday seems to suggest that > > it's pitched at a somewhat lower level of abstraction. > > Yeah, I think wxWindows is pretty ugly when it comes to coding. That's a > serious point in favor of perltk. One point here: perl/tk is just the perl binding to the ptk (read: "portable tk" library). I was "really" suggesting going the library route, although I was going to see if I could get something working through perl just as a proof of concept. Now, I have frequently launched perl scripts from Octave/Matlab functions before to do my evil bidding, but what I haven't done is try to use perl/tk that way. There are issues, of course. > > 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 > > Boy, I just looked at perltk and I have to say that it is a hell of a lot > more appealing than wxWindows and C++. But then again I think Perl is > god's gift to programmers... But like all God's gifts, it can be abused... Anyway, I am certain that wxWindows can do things that Tk cannot, but I'm less certain that Octave needs the full force of what wxWindows can deliver, and wxWindows is pretty large. > I think seriously considering perlTk is a good idea. > It looks portable, am I right? For those who like me have trouble finding > perltk on the WWW: http://www.perl.com/ptk/. I'm not entirely sure how > we would go about using perltk from within octave. Can someone explain this > to me? I've never tried mixing the two languages. Actually, if you want to use perltk to do guis, probably the easiest way to go would be to create a perl program, let's call it "interOctave". interOctave would run the GUI (using perl/tk), collect command line input (with editing) for octave (since perl can use readline, just like Octave), toss commands down a pipe to octave, and page the results back, just like Octave. (There is some tediousness to handle vis-a-vis buffering, but I know it can be solved, and only has to be solved once.) To get graphics, we could do a number of different things. One would be to tell Octave to tell gnuplot (or whomever) to put things in files (and formats?) we like and then read those files and splatter 'em onto our GUI canvas. Then, when the user likes the plot he has and selects the "Print" menu item, we tell octave to tell gnuplot (or whomever) to toss it into the relevant file (or onto the relevant print queue. Now about the gui stuff itself: this is a bit tricky, but not completely horrendous. I think you need to create "shadow" GUI functions as m-files that match Matlab's (or some other interface, if you like) whose sole purpose is to return values that interOctave can grok. Then Octave can do just what it always has, and never have to worry about crappy handle graphics stuff. Hmm, I used to think this approach would be silly. Now I'm not so sure. The charms are many: First, we aren't really asking Octave to do anything it can't already do right now, and people who don't need or like GUIs won't pay any cost to those of us who do. Second, we don't weld Octave to a toolkit we might come to regret, or have to worry how to make a matlab-like language handle graphics commands. You're also leveraging hundreds of person-years of development in both Tk and perl, and probably delighting various people in the perl community, who truly get off on being able to use Perl as universal duct tape. (Today Tk, tomorrow OpenGL, since it's just another Perl module.) It's also possible that this could get off the ground pretty quickly. I'm motivated, and I think I can get a working prototype up pretty quickly. Do you think it's worth a try? [snip!] Well, time's up for me today; I'll write more later. jking