== Quote from Eldar Insafutdinov (e.insafutdi...@gmail.com)'s article > When I saw David's announcement this morning, I remembered that he brought up this topic > sometime ago(about half-year I think) and I promised to have a look at > wrapping Qwt (http:// > qwt.sourceforge.net/) as a part of QtD after we make next release. We never released the next > version of QtD (as usual due to the lack of manpower and time), but we are > still working on > it and hopefully we'll make it soon. I decided not to wait until the release, and try to wrap > Qwt with the development version of QtD. And it worked pretty well! I'm > writing about it not > to belittle David's fantastic work, which was written from scratch and for > sure deserves > admiration, but rather to do what I promised and I hope it will be useful. > So far I haven't ported all classes from the library, but the most difficult part of wrapping > is done, and binding the rest of the classes should be easy, which I will complete shortly. I > ported one of the Qwt examples from C++ to D to give a feel on how to use the binding, which > is available here: http://dsource.org/projects/qtd/browser/examples/qwt/simpleplot . Also, > screencapture of this little program in action: http://img13.imageshack.us/img13/6600/ > simpleplot.png . > The binding is cross-platform, I tested it on Linux and Windows. For the > latter, there are > pre-built packages which can be downloaded from http://dsource.org/projects/qtd/wiki/ > Packages . For linux it should not be difficult to build them from sources, > most of the > distributions contain Qwt. From what I read in the thread there is a problem with saving the > plots, which isn't solved yet. With Qt there are no such problems, any QWidget can be saved > to the pixmap object which you can manipulate as you wish. > There is at least one problem, the mentioned example crashes after you close > the application. > This problem is known and has nothing to do with Qwt, it's a QtD bug, which is currently > being worked on and hopefully we'll resolve the issue. > This is just a result of my one-day experiment. Both dfl+dflplot and QtD+Qwt have their > advantages. dfl has nicer API(I must admit I never used it), dflplot has also more Dish feel, > while Qt and Qwt are more mature and I think more powerful. In the end, we are in the good > position, because we have a choice.
Interesting, though from looking at your SimplePlot code and browsing the Qwt website, it looks like Qwt was designed much more as a set of low-level mechanisms with the "everything must be possible" philosophy. dflplot was designed more with the goal of being as easy to use as, for example, Matlab, in an exploratory context. It has a "simple things must be simple" philosophy. It contains a significant amount of policies as well as mechanisms and has defaults for basically everything, and simple plots can be created in a single line of code. Going off on a tangent a little, my work with dstats and dflplot has convinced me that, given the power of D's metaprogramming facilities, builtin strings and arrays, and fast compile times, there's no reason why, once dflplot and Lars Kyllingstad's SciD mature (I already consider dstats fairly mature), D can't rival Matlab and R in terms of ease of use for scientific and statistical computing, while at the same time being able to do "real" down-and-dirty programming in the same language. I feel dstats has already accomplished this for the small area of 1-d statistics and dflplot is another step in that direction. This vision is what's made me stick with D through all the compiler bugs, breaking spec changes and people looking at me funny when I tell them it's my language of choice. That said, it might be interesting to eventually port my high-level stuff to Qwt, or port it all to qtD. Unless DFL goes cross-platform soon, eventual goal for dflplot is to abstract away most of the GUI code (compile time abstraction; runtime abstraction would create way too much cruft) and port it to whichever cross-platform GUI lib becomes dominant in the D community. The GUI backend would simply be set by a version statement.
