www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Plot2Kill 0.02

reply dsimcha <dsimcha yahoo.com> writes:
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.
Jul 18 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:i1voke$2i9k$1 digitalmars.com...

 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:


I love the new name. And if it ends up being a "killer app" (or really a 
"killer lib") for D, or for data plotting in general, then the name would be 
all the more appropriate :).

This could also be great for providing better benchmarking data (See: 
http://www.zedshaw.com/essays/programmer_stats.html ). D could use this to 
help lead the way in statistically-meaningful benchmark data.
Jul 18 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha Wrote:

 Now that I can't call
 it dflplot anymore because it supports multiple GUI libs, I'm calling it
 Plot2Kill.


The produced image looks good and polished enough. But I suggest to find a
different name.
"dgraphy"? :-)

Bye,
bearophile
Jul 18 2010
prev sibling next sibling parent reply BLS <windevguy hotmail.de> writes:
On 18/07/2010 22:36, dsimcha wrote:

 heat maps


Sorry for my ignorance,
What are heat maps good for ?

Since I am more biz software guy, here my question.

Let's say I have this relation

A Project can have several Cost Centers.
A Cost Center can have several cost items.


I our sample . Project -P- has  say, 10 cost centers.
Cost Center no 1 takes already 60 percent.
The other cost centers (2-10) just take between 10 (blue) and 20 (green) 
percent.

-- So I want to color cost center no 1 related items in red.. . and the 
max percentage item in cost center no 2 dark red.
CC No 1 = {5,20,20,15}

Is this what a heat map is made for ?

and sorry ,  best example I am able to give atm..
bjoern
Jul 18 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from BLS (windevguy hotmail.de)'s article

 On 18/07/2010 22:36, dsimcha wrote:

 heat maps


 Sorry for my ignorance,
 What are heat maps good for ?
 Since I am more biz software guy, here my question.
 Let's say I have this relation
  >A Project can have several Cost Centers.
  >A Cost Center can have several cost items.
 I our sample . Project -P- has  say, 10 cost centers.
 Cost Center no 1 takes already 60 percent.
 The other cost centers (2-10) just take between 10 (blue) and 20 (green)
 percent.
 -- So I want to color cost center no 1 related items in red.. . and the
 max percentage item in cost center no 2 dark red.
 CC No 1 = {5,20,20,15}
 Is this what a heat map is made for ?
 and sorry ,  best example I am able to give atm..
 bjoern


You've pretty much got it.  Heat maps can be thought of as a possible
counterpart
to bar graphs when you want to plot a dependent variable against two independent
variables instead of one.  The "hot" color is used to represent the largest
value
of the dependent variable, the "cold" color is used to represent the smallest
value, and the colors are linearly blended for values in between.

There's also the case of a HeatScatter or 2-D histogram for visualizing a joint
probability distribution.  For small samples, scatter plots are usually used for
this.  However, for large samples, the amount of points on the scatter plot
becomes unwieldy, so instead you bin the data on a 2D grid and the color
represents how often joint realizations with a given pair of values occur.  For
example, the lower right figure in my demo is a HeatScatter where the Y-axis is
distributed Normal(1, 1) and the X-axis is distributed Normal(-2, 1) + Y_i.
Jul 18 2010
parent BLS <windevguy hotmail.de> writes:
On 19/07/2010 00:28, dsimcha wrote:

 You've pretty much got it.


Thanks for your enlightening explanation. I think your plotting tool is 
also very valuable in standard business environments!

I was just a second too late..so sorry for answering twice and making so 
much noise.   bjoern
Jul 18 2010
prev sibling parent reply BLS <windevguy hotmail.de> writes:
On 19/07/2010 00:01, BLS wrote:

 On 18/07/2010 22:36, dsimcha wrote:

 heat maps


 Sorry for my ignorance,
 What are heat maps good for ?

 Since I am more biz software guy, here my question.

 Let's say I have this relation
  >A Project can have several Cost Centers.
  >A Cost Center can have several cost items.

 I our sample . Project -P- has say, 10 cost centers.
 Cost Center no 1 takes already 60 percent.
 The other cost centers (2-10) just take between 10 (blue) and 20 (green)
 percent.

 -- So I want to color cost center no 1 related items in red.. . and the
 max percentage item in cost center no 2 dark red.
 CC No 1 = {5,20,20,15}

 Is this what a heat map is made for ?

 and sorry , best example I am able to give atm..
 bjoern


My guess was okay, Heat maps are also made for this use case. so no need 
to answer.

Since Tree maps are not that different from Heat maps, do you have any 
plans to implement them too ?

Next, Do you have any ideas about zooming ? (zooming a plotting region) ?

and before I forget it again.. Good work David!
bjoern
Jul 18 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from BLS (windevguy hotmail.de)'s article

 On 19/07/2010 00:01, BLS wrote:

 On 18/07/2010 22:36, dsimcha wrote:

 heat maps


 Sorry for my ignorance,
 What are heat maps good for ?

 Since I am more biz software guy, here my question.

 Let's say I have this relation
  >A Project can have several Cost Centers.
  >A Cost Center can have several cost items.

 I our sample . Project -P- has say, 10 cost centers.
 Cost Center no 1 takes already 60 percent.
 The other cost centers (2-10) just take between 10 (blue) and 20 (green)
 percent.

 -- So I want to color cost center no 1 related items in red.. . and the
 max percentage item in cost center no 2 dark red.
 CC No 1 = {5,20,20,15}

 Is this what a heat map is made for ?

 and sorry , best example I am able to give atm..
 bjoern


 My guess was okay, Heat maps are also made for this use case. so no need
 to answer.
 Since Tree maps are not that different from Heat maps, do you have any
 plans to implement them too ?


I didn't have any plans to implement them, as I didn't know about them until I
looked them up on Wikipedia just now.  I'll consider implementing them, but I'm
not sure if it will happen soon.


 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?
Jul 18 2010
next sibling parent BLS <windevguy hotmail.de> writes:
On 19/07/2010 00:44, dsimcha wrote:

 This can already be done programmatically (see Figure.xlim() and
Figure.ylim()),


will have a look.


 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?


Scaling : The solution which comes immediately in mind is by using a 
scale factor. (1.0 by default)

I think the more interesting part is creating a rectangular area within 
your graph. ( I mean press left mouse button and create a rectangle) 
figure out which are the min. and max. values for each of the series, 
depending on the rectangle area. (series  == ranges, I guess)

Dragging ? Not sure what you mean.

bjoern
Jul 18 2010
prev sibling next sibling parent "JimBob" <jim bob.com> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:i2004b$2vvo$1 digitalmars.com...

 == Quote from BLS (windevguy hotmail.de)'s article

 On 19/07/2010 00:01, BLS wrote:

 On 18/07/2010 22:36, dsimcha wrote:

 heat maps


 Sorry for my ignorance,
 What are heat maps good for ?

 Since I am more biz software guy, here my question.

 Let's say I have this relation
  >A Project can have several Cost Centers.
  >A Cost Center can have several cost items.

 I our sample . Project -P- has say, 10 cost centers.
 Cost Center no 1 takes already 60 percent.
 The other cost centers (2-10) just take between 10 (blue) and 20 
 (green)
 percent.

 -- So I want to color cost center no 1 related items in red.. . and the
 max percentage item in cost center no 2 dark red.
 CC No 1 = {5,20,20,15}

 Is this what a heat map is made for ?

 and sorry , best example I am able to give atm..
 bjoern


 My guess was okay, Heat maps are also made for this use case. so no need
 to answer.
 Since Tree maps are not that different from Heat maps, do you have any
 plans to implement them too ?


 I didn't have any plans to implement them, as I didn't know about them 
 until I
 looked them up on Wikipedia just now.  I'll consider implementing them, 
 but I'm
 not sure if it will happen soon.


 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?


What I do in one of my projects is : Press an hold the right mouse button to 
select the point which stays fixed, then dragging up zooms in, dragging down 
zooms out. If you set the zoom to work on an exponential scale it feels 
better also. Ie, scale by pow(2, (mousey-starty)/20), or something like.
Jul 19 2010
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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
Jul 20 2010
parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 20 Jul 2010 06:57:01 -0400, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:


 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


I generally consider mouse-wheel == scroll and crtl + mouse-wheel == zoom
Jul 21 2010
prev sibling parent reply Rory Mcguire <rjmcguire gm_no_ail.com> writes:
dsimcha wrote:


 == Quote from BLS (windevguy hotmail.de)'s article

 On 19/07/2010 00:01, BLS wrote:

 On 18/07/2010 22:36, dsimcha wrote:

 heat maps


 Sorry for my ignorance,
 What are heat maps good for ?

 Since I am more biz software guy, here my question.

 Let's say I have this relation
  >A Project can have several Cost Centers.
  >A Cost Center can have several cost items.

 I our sample . Project -P- has say, 10 cost centers.
 Cost Center no 1 takes already 60 percent.
 The other cost centers (2-10) just take between 10 (blue) and 20
 (green) percent.

 -- So I want to color cost center no 1 related items in red.. . and the
 max percentage item in cost center no 2 dark red.
 CC No 1 = {5,20,20,15}

 Is this what a heat map is made for ?

 and sorry , best example I am able to give atm..
 bjoern


 My guess was okay, Heat maps are also made for this use case. so no need
 to answer.
 Since Tree maps are not that different from Heat maps, do you have any
 plans to implement them too ?


 
 I didn't have any plans to implement them, as I didn't know about them
 until I
 looked them up on Wikipedia just now.  I'll consider implementing them,
 but I'm not sure if it will happen soon.
 

 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?


I don't think that you should hard code something like user interaction, 
just provide the methods for interaction such as:
zoom on reqion(x,y,w,h), user input could be dragging a rectangle
zoom to(here%), user input could be scrolling, ctrl scrolling or a input box
move view(x,y), user input could be scrolling, or holding MMB

-Rory
Jul 22 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s article

 dsimcha wrote:

 == Quote from BLS (windevguy hotmail.de)'s article

 On 19/07/2010 00:01, BLS wrote:

 On 18/07/2010 22:36, dsimcha wrote:

 heat maps


 Sorry for my ignorance,
 What are heat maps good for ?

 Since I am more biz software guy, here my question.

 Let's say I have this relation
  >A Project can have several Cost Centers.
  >A Cost Center can have several cost items.

 I our sample . Project -P- has say, 10 cost centers.
 Cost Center no 1 takes already 60 percent.
 The other cost centers (2-10) just take between 10 (blue) and 20
 (green) percent.

 -- So I want to color cost center no 1 related items in red.. . and the
 max percentage item in cost center no 2 dark red.
 CC No 1 = {5,20,20,15}

 Is this what a heat map is made for ?

 and sorry , best example I am able to give atm..
 bjoern


 My guess was okay, Heat maps are also made for this use case. so no need
 to answer.
 Since Tree maps are not that different from Heat maps, do you have any
 plans to implement them too ?


 I didn't have any plans to implement them, as I didn't know about them
 until I
 looked them up on Wikipedia just now.  I'll consider implementing them,
 but I'm not sure if it will happen soon.


 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?


 I don't think that you should hard code something like user interaction,
 just provide the methods for interaction such as:
 zoom on reqion(x,y,w,h), user input could be dragging a rectangle
 zoom to(here%), user input could be scrolling, ctrl scrolling or a input box
 move view(x,y), user input could be scrolling, or holding MMB
 -Rory


The point isn't to hardcode this directly into the Figure object.  What you
suggest can already be done by calling xLim() and yLim() and then redrawing.
However, Plot2Kill has the concept of a default plot window, which is displayed
by
showAsMain() and returned by getDefaultWindow().  The point of this is so that
if
someone wants to put up a quick plot, they don't need to set up a window
manually.
 At the default plot window level, I don't see either how to avoid hard-coding
this or why hard-coding it would be bad.
Jul 22 2010
parent reply Rory Mcguire <rjmcguire gm_no_ail.com> writes:
dsimcha wrote:


 == Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s article

 dsimcha wrote:




[snip]


 The point isn't to hardcode this directly into the Figure object.  What
 you suggest can already be done by calling xLim() and yLim() and then
 redrawing. However, Plot2Kill has the concept of a default plot window,
 which is displayed by
 showAsMain() and returned by getDefaultWindow().  The point of this is so
 that if someone wants to put up a quick plot, they don't need to set up a
 window manually.
  At the default plot window level, I don't see either how to avoid
  hard-coding
 this or why hard-coding it would be bad.


Ah right.

If you made the app able to select what to use at runtime that would be 
awesome :).


cat data | plot2kill -stdin -gtk
cat data | plot2kill -stdin myplot.png

:D

What can the app currently do?
What have you decided is app and what is lib?
Is the code that draws the lines etc.. pluggable?

:) maybe I should just checkout your code.

I was beginning to feel that D was slow, but then "emplace, scope, enforce 
[Was: Re: Manual...]" in digitalmars.D showed me otherwise, so now I'm all 
excited to try some of the stuff I actually use at work.






-Rory
Jul 22 2010
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s article

 What can the app currently do?
 What have you decided is app and what is lib?


The whole thing is a lib as opposed to an app.  It's just that it's designed to
be
a very high level lib, and has a default plot window.  In other words, if you
don't feel like writing your own window to display the plot in, the lib contains
one with sane defaults for the relevant policies.  You can do something like:

auto myWindow = Histogram(someNumbers, 100).toFigure.getDefaultWindow;
myMainWindow.add(myWindow);
myWindow.showAll();
Jul 22 2010
prev sibling parent reply Johannes Pfau <spam example.com> writes:
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
Jul 19 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.
Jul 19 2010
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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
Jul 19 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.
Jul 19 2010
next sibling parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
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...
Jul 20 2010
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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
Jul 20 2010
next sibling parent "Rory McGuire" <rmcguire neonova.co.za> writes:
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.
Jul 20 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.
Jul 20 2010
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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
Jul 20 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.
Jul 20 2010
next sibling parent reply "Rory McGuire" <rmcguire neonova.co.za> writes:
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
Jul 20 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== 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?
Jul 21 2010
parent reply Johannes Pfau <spam example.com> writes:
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
Jul 21 2010
parent reply Rory Mcguire <rjmcguire gm_no_ail.com> writes:
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
Jul 21 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== 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,

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&amp;id=GuiLibraries&amp;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.
Jul 21 2010
parent reply Rory Mcguire <rjmcguire gm_no_ail.com> writes:
dsimcha wrote:


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

 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&amp;id=GuiLibraries&amp;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.


If you use the pixmap backend of cairo then all one would have to do to
support QT/KDE is add an interface to control the second tier of your
lib.

-Rory
Jul 22 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s article

 dsimcha wrote:

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

 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&amp;id=GuiLibraries&amp;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.


 If you use the pixmap backend of cairo then all one would have to do to
 support QT/KDE is add an interface to control the second tier of your
 lib.
 -Rory


In theory yes, but do we really want to have this many dependencies?  One thing
I'm going to insist on in the management of this project is that there be no
dependencies except for the GUI toolkit being used, so people don't find it
impossible to install.
Jul 22 2010
parent reply Rory Mcguire <rjmcguire gm_no_ail.com> writes:
dsimcha wrote:


 == Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s article

 dsimcha wrote:

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

 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&amp;id=GuiLibraries&amp;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.


 If you use the pixmap backend of cairo then all one would have to do to
 support QT/KDE is add an interface to control the second tier of your
 lib.
 -Rory


 
 In theory yes, but do we really want to have this many dependencies?  One
 thing I'm going to insist on in the management of this project is that
 there be no dependencies except for the GUI toolkit being used, so people
 don't find it impossible to install.


Could the toolkits it uses not be specified on the command line so that it 
only uses the dependencies you choose it to?

e.g.:
dmd *.d -version=gtk
or
dmd *.d -version=cairo_cli
Jul 22 2010
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s article

 dsimcha wrote:

 == Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s article

 dsimcha wrote:

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

 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&amp;id=GuiLibraries&amp;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.


 If you use the pixmap backend of cairo then all one would have to do to
 support QT/KDE is add an interface to control the second tier of your
 lib.
 -Rory


 In theory yes, but do we really want to have this many dependencies?  One
 thing I'm going to insist on in the management of this project is that
 there be no dependencies except for the GUI toolkit being used, so people
 don't find it impossible to install.


 Could the toolkits it uses not be specified on the command line so that it
 only uses the dependencies you choose it to?
 e.g.:
 dmd *.d -version=gtk
 or
 dmd *.d -version=cairo_cli


That's exactly the way it works now, except that for Cairo I'm using the gtkD
Cairo wrappers, rather than "raw" Cairo.  As far as selecting at runtime instead
of compile time, this is almost a definite "won't happen" because IMHO it's
massive overengineering for relatively little benefit, and would make the
project
substantially more complicated in both its internals and its public API.
Jul 22 2010
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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
Jul 20 2010
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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
Jul 20 2010
parent "Rory McGuire" <rmcguire neonova.co.za> writes:
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 :)
Jul 20 2010
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== 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.
Jul 20 2010