Plot2Kill 0.02

[Lars T. Kyllingstad]

On Mon, 19 Jul 2010 17:51:29 +0000, dsimcha wrote:

> == Quote from Johannes Pfau (spam at example.com)'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