== Quote from Lars T. Kyllingstad (public@kyllingen.NOSPAMnet)'s article
> On Tue, 20 Jul 2010 11:37:30 +0000, dsimcha wrote:
> > == Quote from Lars T. Kyllingstad (public@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.

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.

On Tue, 20 Jul 2010 14:37:23 +0200, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from Lars T. Kyllingstad (public@kyllingen.NOSPAMnet)'s article
>> On Tue, 20 Jul 2010 11:37:30 +0000, dsimcha wrote:
>> > == Quote from Lars T. Kyllingstad (public@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.
>
> 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

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

> == Quote from Lars T. Kyllingstad (public@kyllingen.NOSPAMnet)'s article
>> On Tue, 20 Jul 2010 11:37:30 +0000, dsimcha wrote:
>> > == Quote from Lars T. Kyllingstad (public@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

On Tue, 20 Jul 2010 13:29:40 +0000, Lars T. Kyllingstad wrote:

> On Tue, 20 Jul 2010 12:37:23 +0000, dsimcha wrote:
>> 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.

Now I see Rory has already suggested this.

-Lars

On Tue, 20 Jul 2010 15:31:06 +0200, Lars T. Kyllingstad <public@kyllingen.nospamnet> wrote:

> On Tue, 20 Jul 2010 13:29:40 +0000, Lars T. Kyllingstad wrote:
>
>> On Tue, 20 Jul 2010 12:37:23 +0000, dsimcha wrote:
>>> 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.
>
> Now I see Rory has already suggested this.
>
> -Lars

Wasn't quite as specific :)

== Quote from Lars T. Kyllingstad (public@kyllingen.NOSPAMnet)'s article
> 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

Actually...

I've dreamed of the same thing.  I started playing around with writing a CAS about 8 months ago.  It was never a very serious project, i.e. I wrote it in a few days just to see how much functionality I could get working, and never thought it had much of a chance of ever growing into a serious full-fledged CAS.

When I left off, it was capable of parsing a string representing a mathematical expression into a callable object at runtime, performing a few basic mathematical simplifications (not much) and taking derivatives symbolically (though it left the results of these derivatives mostly unsimplified).

I have no intention of developing it further, at least not in the near future, and I'm not sure if it's far enough off the ground to be substantially easier than starting from scratch, but if there's interest I'd be willing to put it up somewhere under the Boost license for others to play around with.

== Quote from Rory McGuire (rmcguire@neonova.co.za)'s article
> Cairo probably makes the most sense. Then you can do pdf, svg, jpg,
> opengl...
> -Rory

This will probably happen fairly soon.  Initially, when I was still just trying to get off the ground and figure out how gtkD (and GUIs in general) worked, I was reluctant to use Cairo because the API seemed more difficult than GTK's native drawing API, and less similar to DFL's drawing API.  Now that things are off the ground and have gone from "make it work" to "make it right", I've written a few small test programs to get a feel for how Cairo works, and figured out how to make it do everything I need it to.

I need to do some serious refactoring first, to separate the drawing logic from the GUI logic, remove baked in assumptions that I'm drawing to a raster surface, encapsulate a bunch of coordinate translation logic, and maybe backport some design improvements to DFL (not hard).  After that I'll probably port the whole GTK version to Cairo.  Question:  After I port the GTK version to Cairo, does anyone still care about the native GDK API version (for compatibility or any other completely unanticipated reason), or should I just completely abandon/discard it and make Cairo the only GTK version?

On 21.07.2010 15:32, dsimcha wrote:
> == Quote from Rory McGuire (rmcguire@neonova.co.za)'s article
>> Cairo probably makes the most sense. Then you can do pdf, svg, jpg,
>> opengl...
>> -Rory
> 
> This will probably happen fairly soon.  Initially, when I was still just trying to get off the ground and figure out how gtkD (and GUIs in general) worked, I was reluctant to use Cairo because the API seemed more difficult than GTK's native drawing API, and less similar to DFL's drawing API.  Now that things are off the ground and have gone from "make it work" to "make it right", I've written a few small test programs to get a feel for how Cairo works, and figured out how to make it do everything I need it to.
> 
> I need to do some serious refactoring first, to separate the drawing logic from the GUI logic, remove baked in assumptions that I'm drawing to a raster surface, encapsulate a bunch of coordinate translation logic, and maybe backport some design improvements to DFL (not hard).  After that I'll probably port the whole GTK version to Cairo.  Question:  After I port the GTK version to Cairo, does anyone still care about the native GDK API version (for compatibility or any other completely unanticipated reason), or should I just completely abandon/discard it and make Cairo the only GTK version?

I think cairo as the only gtk version is fine. Even widgets bundled with gtk are often drawn with cairo.

-- 
Johannes Pfau

Johannes Pfau wrote:

> On 21.07.2010 15:32, dsimcha wrote:
>> == Quote from Rory McGuire (rmcguire@neonova.co.za)'s article
>>> Cairo probably makes the most sense. Then you can do pdf, svg, jpg,
>>> opengl...
>>> -Rory
>> 
>> This will probably happen fairly soon.  Initially, when I was still just
>> trying to get off the ground and figure out how gtkD (and GUIs in
>> general) worked, I was reluctant to use Cairo because the API seemed more
>> difficult than GTK's native
>> drawing API, and less similar to DFL's drawing API.  Now that things are
>> off the ground and have gone from "make it work" to "make it right", I've
>> written a few small test programs to get a feel for how Cairo works, and
>> figured out how to make it do everything I need it to.
>> 
>> I need to do some serious refactoring first, to separate the drawing
>> logic from the GUI logic, remove baked in assumptions that I'm drawing to
>> a raster surface, encapsulate a bunch of coordinate translation logic,
>> and maybe backport some
>> design improvements to DFL (not hard).  After that I'll probably port the
>> whole
>> GTK version to Cairo.  Question:  After I port the GTK version to Cairo,
>> does anyone still care about the native GDK API version (for
>> compatibility or any other completely unanticipated reason), or should I
>> just completely abandon/discard it and make Cairo the only GTK version?
> 
> I think cairo as the only gtk version is fine. Even widgets bundled with gtk are often drawn with cairo.
> 

It might be interesting to see the speed difference, but I think thats about
it.
Do you plan on supporting QT/KDE?

-Rory

== Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
> Do you plan on supporting QT/KDE?
> -Rory

Long term, probably.  Short term, probably not.  QtD is, from what I understand,
not very mature yet.  I had a @#)#* of a time working through bugs, inadequate
documentation, missing features and general lack of polish in gtkD and DFL, and
those are (according to this page:
http://www.wikiservice.at/d/wiki.cgi?action=browse&id=GuiLibraries&oldid=AvailableGuiLibraries)
considered more mature than QtD.

This is not a knock on the developers of these libraries, as I understand that it takes time to create a mature GUI library/binding and the situation is continuously improving.  It's just that it's hard to build on that unstable/immature a foundation.  Once QtD matures to at least the point of DFL and gtkD, I'll seriously consider a port, but until then don't get your hopes up.

On the other hand, once I'm done refactoring things, I hope that the dflwrapper and gtkwrapper files will serve as useful examples, so that others can contribute the code to do a port.  This should not be very hard for someone who already knows a given GUI framework well to write.  Basically, you just need to create a default plot window and subplot widget, and wrap a few drawing primitives in a compile-time interface.