| 1 | | == Project Information == |
|---|
| 2 | | |
|---|
| 3 | | ||Name||'''[[ProjectInfo(name)]]''' |
|---|
| 4 | | ||Category||[[ProjectInfo(cat_name)]] |
|---|
| 5 | | ||Status||[[ProjectInfo(status_id)]] - [[ProjectInfo(status_name)]] |
|---|
| 6 | | ||Short Description||[[ProjectInfo(short)]] |
|---|
| 7 | | ||Long Description||[[ProjectInfo(long)]] |
|---|
| 8 | | ||Forum||[/forums/viewforum.php?f=270] |
|---|
| 9 | | ||Home Page||[[ProjectInfo(home_page)]] |
|---|
| 10 | | |
|---|
| 11 | | 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, and ROC curves. The following are the main goals of the project: |
|---|
| 12 | | |
|---|
| 13 | | 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. |
|---|
| 14 | | |
|---|
| 15 | | 2. Compatibility with all mature, general purpose D GUI toolkits. This so far includes DFL and gtkD/Cairo. 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 simply aren't that much code. |
|---|
| 16 | | |
|---|
| 17 | | 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.) |
|---|
| 18 | | |
|---|
| 19 | | 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. |
|---|
| 20 | | |
|---|
| 21 | | 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 library, and other scientific libraries will likely present more such opportunities. |
|---|
| 22 | | |
|---|
| 23 | | 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. |
|---|
| 24 | | |
|---|
| 25 | | == Project Status == |
|---|
| 26 | | |
|---|
| 27 | | 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 [http://dsource.org/projects/plot2kill/browser/docs/sp.png 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, and import plot2kill.all instead of individual modules (I'll probably refactor what's in what module at some point). |
|---|
| 28 | | |
|---|
| 29 | | 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. |
|---|
| 30 | | |
|---|
| 31 | | 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. |
|---|
| 32 | | |
|---|
| 33 | | == TODO == |
|---|
| 34 | | |
|---|
| 35 | | 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: |
|---|
| 36 | | |
|---|
| 37 | | Make the classes that do the drawing not inherit from or otherwise be tightly coupled to on-screen objects, which will allow Plot2Kill to be used to plot to files from, for example, a console app running in an SSH terminal with no X server. (DONE) |
|---|
| 38 | | |
|---|
| 39 | | Remove the somewhat baked-in assumption that we're always drawing to raster surfaces, and delegate things like rounding to pixels to the individual GUI wrappers. (DONE) |
|---|
| 40 | | |
|---|
| 41 | | Move a bunch of reusable drawing logic from the individual Plot subtypes to Figure, where it belongs. This includes things like coordinate scaling/translation. |
|---|
| 42 | | |
|---|
| 43 | | Backport some design improvements made in the GTK port to the DFL port. (DONE) |
|---|
| 44 | | |
|---|
| 45 | | These will likely be done soon. Until then, all other development is on hold. |
|---|
| 46 | | |
|---|
| 47 | | 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: |
|---|
| 48 | | |
|---|
| 49 | | Line styles (dashed, dotted, etc.) |
|---|
| 50 | | |
|---|
| 51 | | Legends. |
|---|
| 52 | | |
|---|
| 53 | | 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, ...) |
|---|
| 54 | | |
|---|
| 55 | | Customizable colors for axes, labels and plot backgrounds. |
|---|
| 56 | | |
|---|
| 57 | | Dendograms, pie charts. (These require the ability to turn axis drawing off, and I'm not sure how this should work). |
|---|
| 58 | | |
|---|
| 59 | | 3. Improve documentation. |
|---|
| 60 | | |
|---|
| 61 | | 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. |
|---|
| 62 | | |
|---|
| 63 | | == Licensing == |
|---|
| 64 | | Plot2Kill is licensed under the [http://en.wikipedia.org/wiki/Boost_Software_License 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.) |
|---|
| 65 | | |
|---|
| 66 | | 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. |
|---|
| | 1 | Project has moved to Github. https://github.com/dsimcha/Plot2kill |
|---|
