On Tue, 20 Jul 2010 14:37:23 +0200, dsimcha <[email protected]> wrote:
== Quote from Lars T. Kyllingstad ([email protected])'s article
On Tue, 20 Jul 2010 11:37:30 +0000, dsimcha wrote:
> == Quote from Lars T. Kyllingstad ([email protected])'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.
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.
Cairo probably makes the most sense. Then you can do pdf, svg, jpg,
opengl...
-Rory
