digitalmars.D.announce - Plot2Kill 0.02
- dsimcha (36/36) Jul 18 2010 I've successfully ported dflplot to gtkD and gotten it to the point wher...
- Nick Sabalausky (8/20) Jul 18 2010 I love the new name. And if it ends up being a "killer app" (or really a...
- bearophile (5/8) Jul 18 2010 The produced image looks good and polished enough. But I suggest to find...
- BLS (15/18) Jul 18 2010 Sorry for my ignorance,
- dsimcha (13/31) Jul 18 2010 You've pretty much got it. Heat maps can be thought of as a possible co...
- BLS (5/6) Jul 18 2010 Thanks for your enlightening explanation. I think your plotting tool is
- BLS (8/26) Jul 18 2010 My guess was okay, Heat maps are also made for this use case. so no need...
- dsimcha (8/39) Jul 18 2010 I didn't have any plans to implement them, as I didn't know about them u...
- BLS (10/14) Jul 18 2010 Scaling : The solution which comes immediately in mind is by using a
- JimBob (6/51) Jul 19 2010 What I do in one of my projects is : Press an hold the right mouse butto...
- Lars T. Kyllingstad (3/12) Jul 20 2010 How about the mouse wheel? That's always the first thing I try.
- Robert Jacques (3/15) Jul 21 2010 I generally consider mouse-wheel == scroll and crtl + mouse-wheel == zoo...
- Rory Mcguire (7/52) Jul 22 2010 I don't think that you should hard code something like user interaction,...
- dsimcha (8/60) Jul 22 2010 The point isn't to hardcode this directly into the Figure object. What ...
- Rory Mcguire (16/28) Jul 22 2010 Ah right.
- dsimcha (8/10) Jul 22 2010 The whole thing is a lib as opposed to an app. It's just that it's desi...
- Johannes Pfau (12/57) Jul 19 2010 Tested on Linux. Works generally fine, nice work.
- dsimcha (7/62) Jul 19 2010 Yea, I tried to use it on *nix today and realized that. This will get f...
- Lars T. Kyllingstad (6/75) Jul 19 2010 So that was why it kept going SEG-V on me! I tried it out earlier today...
- dsimcha (16/29) Jul 19 2010 Fixed. http://dsource.org/projects/scrapple/changeset/772
- Alix Pexton (4/9) Jul 20 2010 Would it be possible to, instead of rendering a graph to a window
- Lars T. Kyllingstad (7/35) Jul 20 2010 Cool, thanks! :)
- Rory McGuire (3/37) Jul 20 2010 You could re-write it to use GD, its just a drawing library.
- dsimcha (3/7) Jul 20 2010 That, or you want to run the job as a batch job via nohup and have your ...
- Lars T. Kyllingstad (10/17) Jul 20 2010 Ah, I see. I guess the solution which would be most flexible in the lon...
- dsimcha (10/27) Jul 20 2010 Yea, it wouldn't be terribly hard (actually, it would be quite easy sinc...
- Rory McGuire (4/44) Jul 20 2010 Cairo probably makes the most sense. Then you can do pdf, svg, jpg,
- dsimcha (16/19) Jul 21 2010 This will probably happen fairly soon. Initially, when I was still just...
- Johannes Pfau (5/26) Jul 21 2010 I think cairo as the only gtk version is fine. Even widgets bundled with
- Rory Mcguire (5/34) Jul 21 2010 It might be interesting to see the speed difference, but I think thats a...
- dsimcha (18/20) Jul 21 2010 Long term, probably. Short term, probably not. QtD is, from what I und...
- Rory Mcguire (5/33) Jul 22 2010 If you use the pixmap backend of cairo then all one would have to do to
- dsimcha (5/38) Jul 22 2010 In theory yes, but do we really want to have this many dependencies? On...
- Rory Mcguire (7/47) Jul 22 2010 Could the toolkits it uses not be specified on the command line so that ...
- dsimcha (6/53) Jul 22 2010 That's exactly the way it works now, except that for Cairo I'm using the...
- Lars T. Kyllingstad (28/58) Jul 20 2010 I'd start with the cairo wrappers in gtkD, if I were you. To quote the
- Lars T. Kyllingstad (3/11) Jul 20 2010 Now I see Rory has already suggested this.
- Rory McGuire (3/14) Jul 20 2010 Wasn't quite as specific :)
- dsimcha (14/17) Jul 20 2010 Actually...
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
"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
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
On 18/07/2010 22:36, dsimcha wrote:heat mapsSorry 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 relationA 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
== Quote from BLS (windevguy hotmail.de)'s articleOn 18/07/2010 22:36, dsimcha wrote: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.heat mapsSorry 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
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
On 19/07/2010 00:01, BLS wrote:On 18/07/2010 22:36, dsimcha wrote: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! bjoernheat mapsSorry 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
== Quote from BLS (windevguy hotmail.de)'s articleOn 19/07/2010 00:01, BLS wrote: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.On 18/07/2010 22:36, dsimcha wrote: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 ?heat mapsSorry 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.. bjoernNext, 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
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
"dsimcha" <dsimcha yahoo.com> wrote in message news:i2004b$2vvo$1 digitalmars.com...== Quote from BLS (windevguy hotmail.de)'s articleWhat 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.On 19/07/2010 00:01, BLS wrote: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.On 18/07/2010 22:36, dsimcha wrote: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 ?heat mapsSorry 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.. bjoernNext, 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 19 2010
On Sun, 18 Jul 2010 22:44:27 +0000, dsimcha wrote:== Quote from BLS (windevguy hotmail.de)'s articleHow about the mouse wheel? That's always the first thing I try. -LarsNext, 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 20 2010
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:I generally consider mouse-wheel == scroll and crtl + mouse-wheel == zoom== Quote from BLS (windevguy hotmail.de)'s articleHow about the mouse wheel? That's always the first thing I try. -LarsNext, 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 21 2010
dsimcha wrote:== Quote from BLS (windevguy hotmail.de)'s articleI 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 -RoryOn 19/07/2010 00:01, BLS wrote: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.On 18/07/2010 22:36, dsimcha wrote: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 ?heat mapsSorry 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.. bjoernNext, 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 22 2010
== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articledsimcha 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.== Quote from BLS (windevguy hotmail.de)'s articleI 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 -RoryOn 19/07/2010 00:01, BLS wrote: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.On 18/07/2010 22:36, dsimcha wrote: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 ?heat mapsSorry 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.. bjoernNext, 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 22 2010
dsimcha wrote:== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s article[snip]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
== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articleWhat 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
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
== Quote from Johannes Pfau (spam example.com)'s articleOn 18.07.2010 22:36, dsimcha wrote: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.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.
Jul 19 2010
On Mon, 19 Jul 2010 17:51:29 +0000, dsimcha wrote:== Quote from Johannes Pfau (spam example.com)'s articleSo 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. ;) -LarsOn 18.07.2010 22:36, dsimcha wrote: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.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.
Jul 19 2010
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleFixed. 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.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
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
On Tue, 20 Jul 2010 03:22:37 +0000, dsimcha wrote:== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleCool, thanks! :)Fixed. http://dsource.org/projects/scrapple/changeset/772Yea, 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. ;) -LarsI 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
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:You could re-write it to use GD, its just a drawing library.== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleCool, thanks! :)Fixed. http://dsource.org/projects/scrapple/changeset/772Yea, 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. ;) -LarsI 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
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleEven 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. -LarsThat, 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
On Tue, 20 Jul 2010 11:37:30 +0000, dsimcha wrote:== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleAh, 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... ;) -LarsEven 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. -LarsThat, 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
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleOn Tue, 20 Jul 2010 11:37:30 +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. 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.== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleAh, 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... ;) -LarsEven 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. -LarsThat, 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
On Tue, 20 Jul 2010 14:37:23 +0200, dsimcha <dsimcha yahoo.com> wrote:== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleCairo probably makes the most sense. Then you can do pdf, svg, jpg, opengl... -RoryOn Tue, 20 Jul 2010 11:37:30 +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. 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.== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'sarticle-LarsEven 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 haveyourplots 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
== Quote from Rory McGuire (rmcguire neonova.co.za)'s articleCairo probably makes the most sense. Then you can do pdf, svg, jpg, opengl... -RoryThis 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
On 21.07.2010 15:32, dsimcha wrote:== Quote from Rory McGuire (rmcguire neonova.co.za)'s articleI think cairo as the only gtk version is fine. Even widgets bundled with gtk are often drawn with cairo. -- Johannes PfauCairo probably makes the most sense. Then you can do pdf, svg, jpg, opengl... -RoryThis 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
Johannes Pfau wrote:On 21.07.2010 15:32, dsimcha wrote:It might be interesting to see the speed difference, but I think thats about it. Do you plan on supporting QT/KDE? -Rory== Quote from Rory McGuire (rmcguire neonova.co.za)'s articleI think cairo as the only gtk version is fine. Even widgets bundled with gtk are often drawn with cairo.Cairo probably makes the most sense. Then you can do pdf, svg, jpg, opengl... -RoryThis 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
== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articleDo you plan on supporting QT/KDE? -RoryLong 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&id=GuiLibraries&oldid=AvailableGuiLibraries) considered more mature than QtD. This is not a knock on the developers of these libraries, as I understand that it takes time to create a mature GUI library/binding and the situation is continuously improving. It's just that it's hard to build on that unstable/immature a foundation. Once QtD matures to at least the point of DFL and gtkD, I'll seriously consider a port, but until then don't get your hopes up. On the other hand, once I'm done refactoring things, I hope that the dflwrapper and gtkwrapper files will serve as useful examples, so that others can contribute the code to do a port. This should not be very hard for someone who already knows a given GUI framework well to write. Basically, you just need to create a default plot window and subplot widget, and wrap a few drawing primitives in a compile-time interface.
Jul 21 2010
dsimcha wrote:== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articleIf 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. -RoryDo you plan on supporting QT/KDE? -RoryLong 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&id=GuiLibraries&oldid=AvailableGuiLibraries) considered more mature than QtD. This is not a knock on the developers of these libraries, as I understand that it takes time to create a mature GUI library/binding and the situation is continuously improving. It's just that it's hard to build on that unstable/immature a foundation. Once QtD matures to at least the point of DFL and gtkD, I'll seriously consider a port, but until then don't get your hopes up. On the other hand, once I'm done refactoring things, I hope that the dflwrapper and gtkwrapper files will serve as useful examples, so that others can contribute the code to do a port. This should not be very hard for someone who already knows a given GUI framework well to write. Basically, you just need to create a default plot window and subplot widget, and wrap a few drawing primitives in a compile-time interface.
Jul 22 2010
== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articledsimcha wrote: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.== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articlehttp://www.wikiservice.at/d/wiki.cgi?action=browse&id=GuiLibraries&oldid=AvailableGuiLibraries)Do you plan on supporting QT/KDE? -RoryLong 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: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
dsimcha wrote:== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articleCould 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_clidsimcha wrote: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.== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articlehttp://www.wikiservice.at/d/wiki.cgi?action=browse&id=GuiLibraries&oldid=AvailableGuiLibraries)Do you plan on supporting QT/KDE? -RoryLong 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: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
== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articledsimcha wrote: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.== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articledsimcha wrote:== Quote from Rory Mcguire (rjmcguire gm_no_ail.com)'s articleDo you plan on supporting QT/KDE? -RoryLong 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&id=GuiLibraries&oldid=AvailableGuiLibraries)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_cliIn 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.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
On Tue, 20 Jul 2010 12:37:23 +0000, dsimcha wrote:== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleI'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."On Tue, 20 Jul 2010 11:37:30 +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.== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleAh, 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... ;) -LarsEven 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. -LarsThat, or you want to run the job as a batch job via nohup and have your plots appear in some directory the next day.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
On Tue, 20 Jul 2010 13:29:40 +0000, Lars T. Kyllingstad wrote:On Tue, 20 Jul 2010 12:37:23 +0000, dsimcha wrote:Now I see Rory has already suggested this. -LarsYea, 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.
Jul 20 2010
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:Wasn't quite as specific :)On Tue, 20 Jul 2010 12:37:23 +0000, dsimcha wrote:Now I see Rory has already suggested this. -LarsYea, 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.
Jul 20 2010
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s articleNow, if someone made a CAS library for D, I would never again have to reach for any tool other than vim and dmd... ;) -LarsActually... 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