On 18.07.2010 22:36, dsimcha wrote:
> I've successfully ported dflplot to gtkD and gotten it to the point where it works in every way (except speed/memory use; gtkD is a little slow/resource hungry) at least as well as the original DFL version.  Now that I can't call it dflplot anymore because it supports multiple GUI libs, I'm calling it Plot2Kill.  The status of the DFL version hasn't changed since I originally posted about dflplot.  Here's what works and what needs work, with respect to the gtkD version wherever there's a difference:
> 
> Working:  Histograms, bar plots, scatter plots, line plots, QQ plots, ROC curves, heat maps, subplot windows, error bars, rotated text, programmatic saving in raster formats, interactive saving from default plot window (right-clicking brings up a save dialog), zooming in on a single figure from subplot window (double-click on the figure to zoom in).
> 
> Needs work:  Documentation needs improvement and needs to be put up somewhere (will happen once I get my own dsource project, as opposed to Scrapple), saving in vector formats, Cairo port, zooming in on areas within a single figure via the GUI (can be done programmatically), customizability of look and feel of figures (things like fonts, colors, margins, line styles, etc.), general refactoring from "make it work" to "make it right" stage.
> 
> I would say that there will probably not be too many breaking changes (at the source level) to the basic API, i.e. creating a figure and showing it in a default plot window, but the more advanced stuff that you'd care about if you want to integrate plots into your own GUI is likely to be refined via breaking changes.  A stable ABI will probably never happen because it constrains the evolution of the project too much.
> 
> Code:
> 
> http://dsource.org/projects/scrapple/browser/trunk/dflplot/Porting
> 
> Demo figure (created and saved programmatically, no longer a screenshot):
> 
> http://cis.jhu.edu/~dsimcha/plot2killGTK.png
> 
> How to build:  Install gtkD, and then just compile all of the .d files with to a library with -version=gtk.  It doesn't matter if you pass in the DFL files when building the GTK version because all the irrelevant code will be version-statemented out.
> 
> Please let me know if this works properly on OS's besides Windows.  I've only tested it on Windows, although GTK is cross-platform and I only used the high-level gtkD functionality in this lib, so I don't see why it wouldn't work on any other OS with gtkD support.
Tested on Linux. Works generally fine, nice work. Screenshot: http://i.imgur.com/6XS1W.png

There's one problem though:
You use a "veranda" font. I don't know whether that's a typo and you
meant "Verdana" or maybe there is a font called "veranda". But you never
check whether the font becomes null, and so it crashes here (in Size
measureText(string text, Font font)) if I don't change the fonts.
It's not a big deal, I just wanted to let you know, so you can fix it at
some point in time.

-- 
Johannes Pfau

== Quote from Johannes Pfau (spam@example.com)'s article
> On 18.07.2010 22:36, dsimcha wrote:
> > I've successfully ported dflplot to gtkD and gotten it to the point where it works in every way (except speed/memory use; gtkD is a little slow/resource hungry) at least as well as the original DFL version.  Now that I can't call it dflplot anymore because it supports multiple GUI libs, I'm calling it Plot2Kill.  The status of the DFL version hasn't changed since I originally posted about dflplot.  Here's what works and what needs work, with respect to the gtkD version wherever there's a difference:
> >
> > Working:  Histograms, bar plots, scatter plots, line plots, QQ plots, ROC curves, heat maps, subplot windows, error bars, rotated text, programmatic saving in raster formats, interactive saving from default plot window (right-clicking brings up a save dialog), zooming in on a single figure from subplot window (double-click on the figure to zoom in).
> >
> > Needs work:  Documentation needs improvement and needs to be put up somewhere (will happen once I get my own dsource project, as opposed to Scrapple), saving in vector formats, Cairo port, zooming in on areas within a single figure via the GUI (can be done programmatically), customizability of look and feel of figures (things like fonts, colors, margins, line styles, etc.), general refactoring from "make it work" to "make it right" stage.
> >
> > I would say that there will probably not be too many breaking changes (at the source level) to the basic API, i.e. creating a figure and showing it in a default plot window, but the more advanced stuff that you'd care about if you want to integrate plots into your own GUI is likely to be refined via breaking changes.  A stable ABI will probably never happen because it constrains the evolution of the project too much.
> >
> > Code:
> >
> > http://dsource.org/projects/scrapple/browser/trunk/dflplot/Porting
> >
> > Demo figure (created and saved programmatically, no longer a screenshot):
> >
> > http://cis.jhu.edu/~dsimcha/plot2killGTK.png
> >
> > How to build:  Install gtkD, and then just compile all of the .d files with to a library with -version=gtk.  It doesn't matter if you pass in the DFL files when building the GTK version because all the irrelevant code will be version-statemented out.
> >
> > Please let me know if this works properly on OS's besides Windows.  I've only tested it on Windows, although GTK is cross-platform and I only used the high-level gtkD functionality in this lib, so I don't see why it wouldn't work on any other OS with gtkD support.
> Tested on Linux. Works generally fine, nice work.
> Screenshot: http://i.imgur.com/6XS1W.png
> There's one problem though:
> You use a "veranda" font. I don't know whether that's a typo and you
> meant "Verdana" or maybe there is a font called "veranda". But you never
> check whether the font becomes null, and so it crashes here (in Size
> measureText(string text, Font font)) if I don't change the fonts.
> It's not a big deal, I just wanted to let you know, so you can fix it at
> some point in time.

Yea, I tried to use it on *nix today and realized that.  This will get fixed soon.
 In addition to the typo, I forgot that getting a font can return null.  I have no
idea why it works on Windows.  Anyhow, I'll make platform-specific default fonts
(using core X11 fonts on *nix and properly spelled Verdana on Windows) and as a
last resort, if the default font doesn't exist, I'll make it just not render text
instead of crashing the program.

On Mon, 19 Jul 2010 17:51:29 +0000, dsimcha wrote:

> == Quote from Johannes Pfau (spam@example.com)'s article
>> On 18.07.2010 22:36, dsimcha wrote:
>> > I've successfully ported dflplot to gtkD and gotten it to the point where it works in every way (except speed/memory use; gtkD is a little slow/resource hungry) at least as well as the original DFL version.  Now that I can't call it dflplot anymore because it supports multiple GUI libs, I'm calling it Plot2Kill.  The status of the DFL version hasn't changed since I originally posted about dflplot.  Here's what works and what needs work, with respect to the gtkD version wherever there's a difference:
>> >
>> > Working:  Histograms, bar plots, scatter plots, line plots, QQ plots, ROC curves, heat maps, subplot windows, error bars, rotated text, programmatic saving in raster formats, interactive saving from default plot window (right-clicking brings up a save dialog), zooming in on a single figure from subplot window (double-click on the figure to zoom in).
>> >
>> > Needs work:  Documentation needs improvement and needs to be put up somewhere (will happen once I get my own dsource project, as opposed to Scrapple), saving in vector formats, Cairo port, zooming in on areas within a single figure via the GUI (can be done programmatically), customizability of look and feel of figures (things like fonts, colors, margins, line styles, etc.), general refactoring from "make it work" to "make it right" stage.
>> >
>> > I would say that there will probably not be too many breaking changes (at the source level) to the basic API, i.e. creating a figure and showing it in a default plot window, but the more advanced stuff that you'd care about if you want to integrate plots into your own GUI is likely to be refined via breaking changes.  A stable ABI will probably never happen because it constrains the evolution of the project too much.
>> >
>> > Code:
>> >
>> > http://dsource.org/projects/scrapple/browser/trunk/dflplot/Porting
>> >
>> > Demo figure (created and saved programmatically, no longer a
>> > screenshot):
>> >
>> > http://cis.jhu.edu/~dsimcha/plot2killGTK.png
>> >
>> > How to build:  Install gtkD, and then just compile all of the .d files with to a library with -version=gtk.  It doesn't matter if you pass in the DFL files when building the GTK version because all the irrelevant code will be version-statemented out.
>> >
>> > Please let me know if this works properly on OS's besides Windows. I've only tested it on Windows, although GTK is cross-platform and I only used the high-level gtkD functionality in this lib, so I don't see why it wouldn't work on any other OS with gtkD support.
>> Tested on Linux. Works generally fine, nice work. Screenshot:
>> http://i.imgur.com/6XS1W.png There's one problem though:
>> You use a "veranda" font. I don't know whether that's a typo and you
>> meant "Verdana" or maybe there is a font called "veranda". But you
>> never check whether the font becomes null, and so it crashes here (in
>> Size measureText(string text, Font font)) if I don't change the fonts.
>> It's not a big deal, I just wanted to let you know, so you can fix it
>> at some point in time.
> 
> Yea, I tried to use it on *nix today and realized that.  This will get
> fixed soon.
>  In addition to the typo, I forgot that getting a font can return null.
>  I have no
> idea why it works on Windows.  Anyhow, I'll make platform-specific
> default fonts (using core X11 fonts on *nix and properly spelled Verdana
> on Windows) and as a last resort, if the default font doesn't exist,
> I'll make it just not render text instead of crashing the program.

So that was why it kept going SEG-V on me!  I tried it out earlier today, but didn't have time to investigate too much.  It works fine now, and I have the demo window up and running.  Will definitely use for serious work tomorrow. ;)

-Lars

== Quote from Lars T. Kyllingstad (public@kyllingen.NOSPAMnet)'s article
> > Yea, I tried to use it on *nix today and realized that.  This will get
> > fixed soon.
> >  In addition to the typo, I forgot that getting a font can return null.
> >  I have no
> > idea why it works on Windows.  Anyhow, I'll make platform-specific
> > default fonts (using core X11 fonts on *nix and properly spelled Verdana
> > on Windows) and as a last resort, if the default font doesn't exist,
> > I'll make it just not render text instead of crashing the program.
> So that was why it kept going SEG-V on me!  I tried it out earlier today,
> but didn't have time to investigate too much.  It works fine now, and I
> have the demo window up and running.  Will definitely use for serious
> work tomorrow. ;)
> -Lars

Fixed.  http://dsource.org/projects/scrapple/changeset/772

I fired up my barely-used Linux partition for this.  I knew it would come in handy.  I also kludged around the weird text cutoff bugs that only appear on Linux.  (I don't want to say I fixed it because I didn't address the root cause and I don't know what the root cause is.  My best guess is that on Linux the font measurements are slightly off.)

The most serious bug now, IMHO, is that there's no way to save plots to a file from a machine with console-only access, such as a supercomputer that you SSH into.  I don't know how to fix this.  Calling Main.init() on a machine with no windowing system borks everything.  Does anyone have any suggestions on how to fix this?

In general, I want to thank the D community for answering my sometimes naive questions about gtkD and GUIs in general.  Writing this plotting library has been more challenging than most of my projects, as I'd never written a serious GUI app before and am learning how GUI frameworks work on the fly.

On 20/07/2010 04:22, dsimcha wrote:

> The most serious bug now, IMHO, is that there's no way to save plots to a file
> from a machine with console-only access, such as a supercomputer that you SSH
> into.  I don't know how to fix this.  Calling Main.init() on a machine with no
> windowing system borks everything.  Does anyone have any suggestions on how to fix
> this?


Would it be possible to, instead of rendering a graph to a window context, use the drawing commands to generate SVG data?

A...

On Tue, 20 Jul 2010 03:22:37 +0000, dsimcha wrote:

> == Quote from Lars T. Kyllingstad (public@kyllingen.NOSPAMnet)'s article
>> > Yea, I tried to use it on *nix today and realized that.  This will
>> > get fixed soon.
>> >  In addition to the typo, I forgot that getting a font can return
>> >  null. I have no
>> > idea why it works on Windows.  Anyhow, I'll make platform-specific
>> > default fonts (using core X11 fonts on *nix and properly spelled
>> > Verdana on Windows) and as a last resort, if the default font doesn't
>> > exist, I'll make it just not render text instead of crashing the
>> > program.
>> So that was why it kept going SEG-V on me!  I tried it out earlier
>> today, but didn't have time to investigate too much.  It works fine
>> now, and I have the demo window up and running.  Will definitely use
>> for serious work tomorrow. ;)
>> -Lars
> 
> Fixed.  http://dsource.org/projects/scrapple/changeset/772

Cool, thanks! :)


> I fired up my barely-used Linux partition for this.  I knew it would come in handy.  I also kludged around the weird text cutoff bugs that only appear on Linux.  (I don't want to say I fixed it because I didn't address the root cause and I don't know what the root cause is.  My best guess is that on Linux the font measurements are slightly off.)
> 
> The most serious bug now, IMHO, is that there's no way to save plots to a file from a machine with console-only access, such as a supercomputer that you SSH into.  I don't know how to fix this.  Calling Main.init() on a machine with no windowing system borks everything.  Does anyone have any suggestions on how to fix this?

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

On Tue, 20 Jul 2010 09:53:02 +0200, Lars T. Kyllingstad <public@kyllingen.nospamnet> wrote:

> On Tue, 20 Jul 2010 03:22:37 +0000, dsimcha wrote:
>
>> == Quote from Lars T. Kyllingstad (public@kyllingen.NOSPAMnet)'s article
>>> > Yea, I tried to use it on *nix today and realized that.  This will
>>> > get fixed soon.
>>> >  In addition to the typo, I forgot that getting a font can return
>>> >  null. I have no
>>> > idea why it works on Windows.  Anyhow, I'll make platform-specific
>>> > default fonts (using core X11 fonts on *nix and properly spelled
>>> > Verdana on Windows) and as a last resort, if the default font doesn't
>>> > exist, I'll make it just not render text instead of crashing the
>>> > program.
>>> So that was why it kept going SEG-V on me!  I tried it out earlier
>>> today, but didn't have time to investigate too much.  It works fine
>>> now, and I have the demo window up and running.  Will definitely use
>>> for serious work tomorrow. ;)
>>> -Lars
>>
>> Fixed.  http://dsource.org/projects/scrapple/changeset/772
>
> Cool, thanks! :)
>
>
>> I fired up my barely-used Linux partition for this.  I knew it would
>> come in handy.  I also kludged around the weird text cutoff bugs that
>> only appear on Linux.  (I don't want to say I fixed it because I didn't
>> address the root cause and I don't know what the root cause is.  My best
>> guess is that on Linux the font measurements are slightly off.)
>>
>> The most serious bug now, IMHO, is that there's no way to save plots to
>> a file from a machine with console-only access, such as a supercomputer
>> that you SSH into.  I don't know how to fix this.  Calling Main.init()
>> on a machine with no windowing system borks everything.  Does anyone
>> have any suggestions on how to fix this?
>
> 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

You could re-write it to use GD, its just a drawing library.

On Sun, 18 Jul 2010 22:44:27 +0000, dsimcha wrote:
> == Quote from BLS (windevguy@hotmail.de)'s article

>> Next, Do you have any ideas about zooming ? (zooming a plotting region)
>> ?
> 
> This can already be done programmatically (see Figure.xlim() and
> Figure.ylim()), but is not exposed yet via the default plot window GUI.
> This will be exposed when I decide how I want to expose it.  The most
> obvious answer is dragging, but the question then becomes, how do you
> zoom back out?

How about the mouse wheel?  That's always the first thing I try.

-Lars

== 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.

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