Plot2Kill 0.02

[Lars T. Kyllingstad]

On Tue, 20 Jul 2010 12:37:23 +0000, dsimcha wrote:

> == Quote from Lars T. Kyllingstad (public at kyllingen.NOSPAMnet)'s article
>> On Tue, 20 Jul 2010 11:37:30 +0000, dsimcha wrote:
>> > == Quote from Lars T. Kyllingstad (public at kyllingen.NOSPAMnet)'s
>> > article
>> >> Even if you SSH into it, you can still run GUI apps remotely using X
>> >> forwarding.  But if you're saying that the machine doesn't have X
>> >> installed at all (do those still exist?), I have no suggestions.
>> >> -Lars
>> >
>> > That, or you want to run the job as a batch job via nohup and have
>> > your plots appear in some directory the next day.
>> Ah, I see.  I guess the solution which would be most flexible in the
>> long run would be to make the GUI abstraction "abstract enough" that it
>> isn't limited to GUIs -- sort of like gnuplot does with its notion of
>> 'terminals'.  Then backends could be created for writing to various
>> file formats.  But that's probably quite a lot of work. I started using
>> Plot2Kill "for real" at work today, BTW, and it works very well.  Now,
>> if someone made a CAS library for D, I would never again have to reach
>> for any tool other than vim and dmd... ;) -Lars
> 
> Yea, it wouldn't be terribly hard (actually, it would be quite easy
> since I wouldn't need to get all the GUI stuff right) to port Plot2kill
> to a GUI-less drawing framework, if one existed that a decent D
> binding/wrapper.  I'm guessing that at best, I'd find a binding to some
> low-level C API if I looked, though.

I'd start with the cairo wrappers in gtkD, if I were you.  To quote the 
Wikipedia page:
    "cairo is a software library used to provide a vector graphics-based, 
device-independent API for software developers. It is designed to provide 
primitives for 2-dimensional drawing across a number of different 
backends."


> In the meantime, to prepare for such a possibility, I should probably
> refactor some stuff to completely separate the drawing logic from the
> GUI logic, i.e. Figure should not inherit from DrawingArea, but should
> instead have a toWidget() method that returns a DrawingArea subclass
> that has-a Figure that is automatically drawn onto it.

To me, at least, it isn't obvious where to draw the line between frontend 
and backend.  You want to hit the sweet spot between DRY and maximum 
flexibility.

For instance:  Does a backend expose a set of drawing primitives and let 
the frontend do the drawing, or does it take the raw data and the plot 
configuration and draw the plot itself?

Or perhaps a three-layered solution would be better?  Suggestion:

Frontend:
  Takes input data and a description of the desired
  output, selects middle layer and backend accordingly.

Middle layers:
  vector:  Draws vector graphics on backends that expose
           vector drawing primitives.
  raster:  Draws raster graphics on backends that expose
           raster drawing primitives.
  trivial: Just passes the raw data to some backend.

Backend:
- For the vector middle layer you'd have on-screen, SVG, EPS, etc.
- For the raster middle layer you'd have GIF, PNG, etc.
- For the trivial middle layer you could have just about anything.

-Lars