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

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 next 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

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

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

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

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?

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:


 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 next sibling parent "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
prev sibling 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 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.

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
next sibling 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.

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

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

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
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, 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&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, 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&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, 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&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.

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, 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&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.

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, 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&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.

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.

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 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
prev sibling next sibling parent "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.

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
prev sibling next sibling parent "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.

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
prev sibling 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.

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 next sibling parent "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
prev sibling next sibling parent "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  

 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.  


 That, or you want to run the job as a batch job via nohup and have  

 plots appear in some directory the next day.

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
prev sibling next sibling parent "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.

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
prev sibling next sibling parent "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
prev sibling 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