From octave-graphics-request at bevo dot che dot wisc dot edu Sun Jul 30 11:59:53 2000 Subject: RE: handel graphics From: "Julian A. de Marchi, Ph.D." To: Date: Sun, 30 Jul 2000 12:59:50 -0400 : : Those who are C++ programmers should make proposals to this : list before engaging on the project. : : : Two months ago I sent an initial GTK+ implementation of jwe Octave GUI My feeling is if we can ensure that GTK+ is scalable and generic, we can use it. If it works with PlPlot or whatever, so much the better, particularly if PlPlot does the trick. It seems to me the key is a GUI that: 1) has widgets as well as plots (easy-to-generate ones) 2) can generate signals/events on user interaction, and vice-versa 3) can be wrapped with any of several other scripting languages, exempli gratia, tcl/Tk and Handle Graphics (TM) and so on For the c++ API we simply need a good design. This is OOD and should be drawn up by some folks with the requisite software design experience. jwe made a point that the broader our collective experience, the better for our c++ API design. On the other hand, we're in a quagmire here. So why not try a top-down start to the design? Implement Matlab's Handle Graphics (TM) interface using a commonplace, well-accepted, GNU GPL tool- set in the most natural manner, and later we'll wrap it to mate with the c++ API? In other words, we can I think start on the function before the form is worked out (up to a significant point). ..so, PlPlot and GTK+ it is? Let's decide. Even if PlPlot is not the ultimate solution (CORBA's been tossed about I see), then it'll be one of the possible implementations, hooking into a generic c++ API. We must understand the two issues ARE separable. A "working" GUI will be a great incentive (and perhaps even guidance) as to what that generic API ought to include, or how it might be designed, by "deconstructing" the compo- nents of the implementation we develop. I am certain that most of the relevant issues will automatically surface over the course of such a development process. : Of course all us can discuss things like the script user "API". For : example, should it be Matlab compatible? The same applies to the : graphics script "API". jwe's structure-oriented Octave interface is certainly a lot easier to use than Matlab's Handle Graphics. _Handel_ Graphics should be much more elegant, don't you agree? I think we can (and should) provide parallel compatibility, though, and this can be a great start in terms of testing functionality for compatibility using code we've all already developed under Matlab. Ultimately, we'll set ourselves up to do better. So I'd propose we start with PlPlot (btw, does epsTk find any use in here?). Let jwe et alii make the call on GTK+ or what not. Get a pl-based API up and running with the right "look and feel" to match what The Mathworks' has already got. Keep this broken up as component GUI elements. By then we may have the c++ API already sorted. We can get some widgets ready for use across platforms in the meantime. A key issue will be, how do we avoid bloating Octave just so guitools can be implemented? jwe chose Athena for this reason. How big is PLPlot? Does it really replace GNUPlot? Does it make widgets any easier than tcl/tk? What doesn't epsTk do that PLPlot does? ...More circular questions. Unless we sell whatever idea makes the most sense from a technical perspective, we'll continue to go round the merry-go-round. : In my opinion, designing a C++ library-independent API will be almost : impossible and doomed to inaction. I also think that when (if) designing : the API, one should have single libraries and not desktop environments : in mind. Let's narrow it down to 2-3 sensible choices, detail ALL the pros and cons, and then commit to an immediate don't-hold-your-breath decision. Waiting for Godeau (read: CORBA, or c++ API) will again quash our enthusiasm to get going. Sometimes having something up and running and ready to contribute and integrate is the best kind of consensual motivator. : I tried to make a C API design exercice for plotting, with gnuplot, : plplot and pgplot in mind, and I gave up after a while: there are many : different ways of doing the same thing in any of them, and I couldn't : find a common framework. Case in point. : > > Meanwhile, I have the inane suggestion to term Octave's : graphics API (the : > > script-level one) "Handel Graphics", further confusing the : origin of the : > > term "Octave", paying respects to a great composer at the : same time, and : > > further (falsely) insinuating that "Octave" has anything to : do with music : > > whatsoever. More than anything it's a trump for Matlab, : since Handel has : > > obviously offered the world loads more than Handle Graphics : (TM) ever could. : > : > Very nice: "Handel (Graphics) makes Octave wonderfully sound". : : I agree! Can this be the first step? : GREAT! I LOVE IT! Thanks for liking the idea. Of course, I'm partial. But I think it's an elegant/suave "touché", if you will. : But does the name means that we will stick to the "handle" concept or : not? (even the first step is hard...) I should think resolutely NOT. It just means we will, at some point, be able to backward-comptibly "handel" Handle Graphics in addition to the better, streamlined, structure-based approach jwe proposed. I'm excited to get going! Looking forward to your input, Julian