From graphics-request at octave dot org Mon Jul 5 12:47:45 2004 Subject: Re: OctPlot - yes it's yet another handle graphics package for octave From: Shai Ayal To: Paul Kienzle Cc: graphics at octave dot org Date: Mon, 05 Jul 2004 20:43:38 +0300 Paul, I appreciate the pointers and guidance. Paul Kienzle wrote: > Please keep a clean separation between graphics toolkit and > plotting. E.g., 3D plots should only have the open gl window > handle, not the handle of the toolkit which wraps them. This is the way I did it, all the graphic object classes (line, patch, axis...) draw using only OpenGL commands. A big exception is the text object, since OpenGL has no native support for text, this has to be implemented through fltk. > Work with other groups. Well, I know that if we all cooperate we'll probably achieve more, but I am writing this as a hobby at my own pace, and I really wanted to go through all the parts of doing this -- design, programming etc.. I am not sure that I want to become part of a group which already has quite robust ideas about their design (which I might not agree with). I am also not very interested in conforming to a group's deadlines and milestones etc... -- I already "enjoy" this very much at work. > Find code in knewplot and oplot that you > can use (much easier if either were implemented independently > from a particular toolkit). Separate it cleanly, improve it and feed > it back to them. I am borrowing from octave-forge (mainly config stuff), and the seemingly defunct knewplot. > > Do the UI in a high level scripting language. Either octave (eat > your own dogfood), or Tcl or Python. I know Tcl/Tk has an > active community developing UI widgets, which means less work > for you. Unfortunately, it is not as organized as it should be, so > you get lots of different implementations of the same widgets > (sound familiar?). I don't agree with you here. I'm no expert on tcl/tk but it seems to me that you pay a large penalty: It is large, it creates more dependencies in the code, and it is probably slow. It is also not exactly what I need. This means it will turn into another octave/gnuplot affair -- we now have gnuplot which is a superb plotting tool, but it does not exactly fit into the octave world. At first it was great, but as we became more and more spoiled, we saw the little annoying things -- so much octave-forge code is written to work around these little annoyances, but still no good way to get data from gnuplot ! still very slow ascii transfers of data etc... So comes the age of an octave specific plotting package. It is no coincidence IMHO that so many packages appeared at almost the same time. > I suppose Gtk/Fltk/Qt offers the same benefits, > except that the widgets are in C. For the common widgets, use a > common interface so that another toolkit can be substituted when > fltk gets crufty. This is pretty much dictated by the desire for > compatibility anyway. The reason I chose fltk as the underlaying toolkit is that it is very small and easy to install. My own experience in trying to install new versions of Qt and KDE on somewhat older (rh 7.2) systems is very bad. These are giant toolkits and they tie the application to them too much. In fltk I think I found something which is manageable -- one can even statically link it to the executable and it stays a reasonable size! > Don't short change printing. Working scientists need to include > plots in their log books. BTW, TeX-like math markup in plot > labels would be nice. You might want to look at some mathml > renderers (e.g., gtkmathml or amaya), or others (e.g., texmacs). I totally agree with you on this point quality vector hardcopy is essential to any plotting package. And as quality goes, postscript is the king here. It is a vector format and can be converted to almost everything using gs. One of the big put-offs in knewplot for me was lack of good postscript output. octplot has postscript output, implemented using gl2ps library which translates the OpenGL command pipeline to vector ps files. This way you get very good hardcopy. a subset of the TeX parser is also on my todo list, I thought about converting the enhanced ps code from gnuplot to TeX syntax > To paraphrase Newton, we can see farther standing on each > other's shoulders. As a former astrophysicist I cannot argue with Newton (although I seem to recall that he was a pretty selfish man himself). I accept your main argument that I should make everything as modular as possible so others can borrow from me easily. I will try to do so in every place possible. However I do not think I will join another project or start using a high level language for the UI stuff. My main goal is to match octave with the graphics power it deserves and do so in a matlab compatible way. Shai Ayal > > On Jul 4, 2004, at 2:41 PM, Shai Ayal wrote: > >> Hi all >> >> I'm happy to announce release 0.1 of OctPlot, a handle graphics >> package for Octave, striving to become a superset of M*tlab handle >> graphics. It is available on >> >> http://sourceforge.net/projects/octplot/ >> >> Octplot's claim to fame is that is it based on fltk, the small fast >> toolkit. It is cross platform and runs natively on linux and cygwin >> (no X required for cygwin). It is tested on Linux (rh9, fc1) and >> cygwin, and should theoretically work on the Mac OS X also. >> >> As most of the other packages out there, it also utilizes OpenGL for >> possible hardware acceleration. >> >> Currently octplot does the following: >> 2D line plots using the commands "plot" , "line" >> property setting and query using the commands "set" ,"get" >> multiple figures using "figure" >> axis limits set and query using the command "axis" >> axis zoom using the mouse (zoom using left button, unzoom using right). >> Quality postscript output using the command "print" >> >> A sample session: >> >> cd octplot-0.1/src ## sorry, no install script yet >> octave ## tested with 2.1.49, 2.1.50 and 2.1.57, and octave-forge >> setup_octplot ## this sets up dispatch etc... >> h=plot(sin((0:10000)/10000*2*pi,'g-"); ## plot a line & get handle >> get(h); ## shows all available properties >> set(h,linestyle,"--","linewidth,3,marker,"+"); ## set a few of them >> ## now play with the mouse to zoom in and out :) >> >> As you see release 0.1 has limited functionality and I put it out >> there mainly to get feedback, so don't hesitate. Please use the >> sourceforge feedback mechanism. >> >> future plans -- >> add patch, subplots, TeX parsing of text, uicontrols, 3D ... >> >> >> Enjoy It, I know I did >> Shai >> > >