Overview

Plot2Kill is a 2D plotting library for D2. It's capable of drawing basic scientific and statistical plots, including bar graphs, line graphs, histograms, scatter plots, heat maps, quantile-quantile plots, dendrograms and ROC curves. The following are the main goals of the project:

1. Present a high-level interface similar to Matlab, R or Python's Matplotlib library. Creating a simple plot and displaying it on the screen or saving it to a file should be no more than 1-2 lines of code. Everything feasible (fonts, line widths, colors, sizes, axis ticks, plot windows, etc.) must have a reasonable default.

2. Compatibility with all mature, general purpose D GUI toolkits. This so far includes DFL and gtkD/Cairo. Eventually it should be expanded to QtD and DWT2. I have higher priority hacking jobs right now, but I'd accept contributions of these ports. Basic 2D plotting really only relies on a small set of primitives: Lines, rectangles, text, a default plot window and a subplot widget. The interfaces for drawing lines, rectangles and text can be easily abstracted into a compile time interface for each plotting library, and the default plot window and subplot widget aren't that much code.

Eventually, I hope to have a reasonably well-defined compile-time interface for others to program to if you want to port Plot2Kill to your favorite GUI framework, but this isn't at all stable yet. (See status.)

As far as API compatibility across GUI toolkits, of course the API is going to be somewhat GUI framework specific. However, the goal is to at least have the simplest use cases (creating a plot and displaying it as the main window or saving it to a PNG file) work the same on any supported GUI framework.

3. Eventually, once other scientific libraries for D mature, integration with them should be done. I can already see several opportunities for this with regard to my dstats and SciD libraries.

4. Last and definitely least, customizability and features. While it's nice to be able to get the exact look and feel you want (I'm certainly not against that) I believe that ease of use and compatibility are higher priorities to spend our limited manpower on. I personally almost never use any of the advanced plotting features of R, Matlab or Matplotlib, advanced being defined as anything Plot2Kill doesn't currently support. At least in the near term, Plot2Kill is not for people who want to customize every detail of their plots.

Project Status

Plot2Kill is currently in the alpha stage. It's past the initial "make it work" stage and can be considered usable at this point. See this sample image to get an idea of its current capabilities. The API for the simplest use cases (creating a figure, saving it to a file, and getting a control/widget or default plot window that contains it) will probably remain reasonably stable, because it's clean, simple and effective. I can't guarantee zero breaking changes, but they should be few and relatively minor as long as you use the Plot2Kill wrappers for things like obtaining Color objects, Font objects and default plot windows rather than using the GUI framework directly.

The API for more complex/advanced stuff like integrating plots into your own GUIs, drawing them onto your own drawable objects, etc. is starting to stabilize after a major refactoring, but I wouldn't call it stable yet. The API for creating your own plot types is definitely going to be refactored mercilessly, so you might want to hold off on this.

At an ABI level, Plot2Kill will probably never be stable. It's intended to be a small, simple, statically linked library, so a stable ABI would only be an unnecessary constraint. I fully reserve the right to break the ABI at any time, in any way, for any reason, and without any notice.

TODO

1. Plot2Kill is in severe need of refactoring to remove some design decisions from the initial "make it work" phase that proved bad in hindsight. The most important items here are:

Refactor the translation between plot unit coordinates and pixel coordinates from mixins to objects. I made the decision to use mixins late at night and it's stuck due to inertia. This would probably have tons of ripple effects, so I've been putting it off, but it's really bad design.

2. While ultra-high customizability/feature richness is not high on the list, a few more options and features do need to be exposed. In particular, we need:

Line styles (dashed, dotted, etc.)

Log-scale plots. (You can just use map!log10(myData), but the axis scales won't be log. They'll have 1, 2, 3, ... instead of 10, 100, 1000, ...)

Customizable colors for axes, labels and plot backgrounds.

3. Get the documentation to compile. (It doesn't now due to DMD bug 5704.)

4. Porting to more GUI toolkits as they become reasonably stable. I'd like to make the compile-time interface for doing so clear and stable enough that others can easily port Plot2Kill to their favorite GUI framework without having to understand the whole codebase inside out.

Licensing

Plot2Kill is licensed under the Boost license. You may not be able to use it under such permissive terms if you link to a copylefted GUI library. For example, GTK and gtkD are LGPL, which adds some (minor) requirements to executables that link to it, but imposes no burdens on source code that simply refers to the LGPL'd library. (The sources to this project, in isolation, would be considered a "work that uses the library" and fall outside the scope of the LGPL.)

As far as porting to GPL'd GUI frameworks, this will not happen unless it is unambiguously shown that this could be done without making this whole project, including the GUI-agnostic code and the wrappers to non-GPL'd GUI libs, fall under the GPL's copyleft. If you're a copyright lawyer or otherwise a software licensing expert and want to port to a GPL'd GUI framework, please speak up on this issue.