From graphics-request at octave dot org Mon Jul 5 16:34:55 2004 Subject: Re: OctPlot - yes it's yet another handle graphics package for octave From: Paul Kienzle To: Shai Ayal Cc: graphics at octave dot org Date: Mon, 5 Jul 2004 17:33:54 -0400 On Jul 5, 2004, at 1:43 PM, Shai Ayal wrote: > 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. There are a couple of independent libraries for handling fonts, such as ftgl+freetype2. I don't know how big they are, or how well they work though. >> 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. To create scientific user interfaces, you need to be able to compose widgets (including plot widgets) into an application. Whatever tools octave settles on to do this (assuming it ever does), it should use the same tools for interfacing with figures and plots. As I said above, wrapping gtk or fltk is one way of achieving this. Octave already provides the scripting glue so you are well on your way to having a GUI scripting language. You will need to do some work making the interface smooth. An alternative is to embed octave in Tcl/Tk. Tcl/tk adds about 900 kb to the executable, and I have another 900k of add-on packages. It has very broad cross-platform support. The big advantage to using Tcl/Tk for the GUI is that a number of composite widgets have already been done for you. Another advantage is speed. I planned to do much more of my apps in octave and restrict tcl/tk to just the user interface, but the octave interpreter was too slow for my needs, and so I moved data file parsing into Tcl/tk as well. > >> 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! Ease of distribution is important, both for the development environment and the resulting applications. To plug Tcl/Tk again, starkits are wonderful. You can bundle all your scripts and binaries into a single file executable. Now I don't care what is installed on the system. Users can download my 2Mb bundle and it contains the application plus all the environment it needs. Of course octave could be extended to do the same, but the binaries involved would be much bigger. > >> 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 Too bad gs isn't native on windows. Are there gl2pdf libraries in the works? > >> 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). Hence the need to paraphrase. Leibniz wouldn't be able to lay any claim to the invention of calculus if Newton hadn't sat on his work for twenty some years. > 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. Yes, evolution will eventually settle upon a good solution to any given problem. Just remember that it takes geological time and lots of individuals to do it ;-) - Paul