On Mon, 19 Jul 2010 17:51:29 +0000, dsimcha wrote: > == Quote from Johannes Pfau ([email protected])'s article >> On 18.07.2010 22:36, dsimcha wrote: >> > I've successfully ported dflplot to gtkD and gotten it to the point >> > where it works in every way (except speed/memory use; gtkD is a >> > little slow/resource hungry) at least as well as the original DFL >> > version. Now that I can't call it dflplot anymore because it >> > supports multiple GUI libs, I'm calling it Plot2Kill. The status of >> > the DFL version hasn't changed since I originally posted about >> > dflplot. Here's what works and what needs work, with respect to the >> > gtkD version wherever there's a difference: >> > >> > Working: Histograms, bar plots, scatter plots, line plots, QQ plots, >> > ROC curves, heat maps, subplot windows, error bars, rotated text, >> > programmatic saving in raster formats, interactive saving from >> > default plot window (right-clicking brings up a save dialog), zooming >> > in on a single figure from subplot window (double-click on the figure >> > to zoom in). >> > >> > Needs work: Documentation needs improvement and needs to be put up >> > somewhere (will happen once I get my own dsource project, as opposed >> > to Scrapple), saving in vector formats, Cairo port, zooming in on >> > areas within a single figure via the GUI (can be done >> > programmatically), customizability of look and feel of figures >> > (things like fonts, colors, margins, line styles, etc.), general >> > refactoring from "make it work" to "make it right" stage. >> > >> > I would say that there will probably not be too many breaking changes >> > (at the source level) to the basic API, i.e. creating a figure and >> > showing it in a default plot window, but the more advanced stuff that >> > you'd care about if you want to integrate plots into your own GUI is >> > likely to be refined via breaking changes. A stable ABI will >> > probably never happen because it constrains the evolution of the >> > project too much. >> > >> > Code: >> > >> > http://dsource.org/projects/scrapple/browser/trunk/dflplot/Porting >> > >> > Demo figure (created and saved programmatically, no longer a >> > screenshot): >> > >> > http://cis.jhu.edu/~dsimcha/plot2killGTK.png >> > >> > How to build: Install gtkD, and then just compile all of the .d >> > files with to a library with -version=gtk. It doesn't matter if you >> > pass in the DFL files when building the GTK version because all the >> > irrelevant code will be version-statemented out. >> > >> > Please let me know if this works properly on OS's besides Windows. >> > I've only tested it on Windows, although GTK is cross-platform and I >> > only used the high-level gtkD functionality in this lib, so I don't >> > see why it wouldn't work on any other OS with gtkD support. >> Tested on Linux. Works generally fine, nice work. Screenshot: >> http://i.imgur.com/6XS1W.png There's one problem though: >> You use a "veranda" font. I don't know whether that's a typo and you >> meant "Verdana" or maybe there is a font called "veranda". But you >> never check whether the font becomes null, and so it crashes here (in >> Size measureText(string text, Font font)) if I don't change the fonts. >> It's not a big deal, I just wanted to let you know, so you can fix it >> at some point in time. > > Yea, I tried to use it on *nix today and realized that. This will get > fixed soon. > In addition to the typo, I forgot that getting a font can return null. > I have no > idea why it works on Windows. Anyhow, I'll make platform-specific > default fonts (using core X11 fonts on *nix and properly spelled Verdana > on Windows) and as a last resort, if the default font doesn't exist, > I'll make it just not render text instead of crashing the program.
So that was why it kept going SEG-V on me! I tried it out earlier today, but didn't have time to investigate too much. It works fine now, and I have the demo window up and running. Will definitely use for serious work tomorrow. ;) -Lars
