I'm thinking of giving another try to writing a plotting library for D.  I'm trying to decide what GUI library to use.  Here's what's important to me, in order of importance.  Someone who's more familiar with the GUI library situation than I am please make a recommendation.

1.  Good D2 support.  I don't want something that's going to take forever to be usable in D2 even after the spec is stable.

2.  Performance.  If a scatter plot with 50,000 points takes a few seconds to redraw when the window is resized, it's too slow.  I'm frankly sick of using slow plotting libraries in other languages.

3.  Licensing.  I prefer something permissive like BSD or Boost.  LGPL is acceptable, though annoying and sometimes ambiguous.  If it's GPL I just plain won't use it because I want the license to the plotting library to be reasonably permissive.

4.  Simplicity of API.  I don't want a library that requires tons of boilerplate to do simple things.

5.  Platform support.  Windows XP, Vista and 7 and x86 Linux are a must.  I don't care so much about macs or some of the more esoteric platforms, or about ancient versions of Windows.

What isn't very important:

1.  Lots of features/flexibility.  I'm thinking the plotting lib will be a minimalist library, focused on "just working", simplicity of API and performance rather than on lots of bells and whistles and extensibility. Therefore, I don't need lots of bells and whistles in my GUI library.

2.  Native look and feel.  IMHO this is very overrated.  I've never found that a Java-ish or GTK-ish or whatever look and feel instead of a native Win32 look and feel got in the way of me using a program effectively.

3.  Stable ABI.  The plotting library will never have a stable ABI, only a stable source-level API.  Most of the API will probably be templates anyhow. Therefore, I don't care if the GUI library has no stable ABI, only a stable source-level API.

dsimcha дµ½:

> I'm thinking of giving another try to writing a plotting library for D.  I'm trying to decide what GUI library to use.  Here's what's important to me, in order of importance.  Someone who's more familiar with the GUI library situation than I am please make a recommendation.
> 
> 1.  Good D2 support.  I don't want something that's going to take forever to be usable in D2 even after the spec is stable.
> 
> 2.  Performance.  If a scatter plot with 50,000 points takes a few seconds to redraw when the window is resized, it's too slow.  I'm frankly sick of using slow plotting libraries in other languages.
> 
> 3.  Licensing.  I prefer something permissive like BSD or Boost.  LGPL is acceptable, though annoying and sometimes ambiguous.  If it's GPL I just plain won't use it because I want the license to the plotting library to be reasonably permissive.
> 
> 4.  Simplicity of API.  I don't want a library that requires tons of boilerplate to do simple things.
> 
> 5.  Platform support.  Windows XP, Vista and 7 and x86 Linux are a must.  I don't care so much about macs or some of the more esoteric platforms, or about ancient versions of Windows.
> 
> What isn't very important:
> 
> 1.  Lots of features/flexibility.  I'm thinking the plotting lib will be a minimalist library, focused on "just working", simplicity of API and performance rather than on lots of bells and whistles and extensibility. Therefore, I don't need lots of bells and whistles in my GUI library.
> 
> 2.  Native look and feel.  IMHO this is very overrated.  I've never found that a Java-ish or GTK-ish or whatever look and feel instead of a native Win32 look and feel got in the way of me using a program effectively.
> 
> 3.  Stable ABI.  The plotting library will never have a stable ABI, only a stable source-level API.  Most of the API will probably be templates anyhow. Therefore, I don't care if the GUI library has no stable ABI, only a stable source-level API.


extend DFL or ports  wxWidgets .
thanks

dolive

dsimcha дµ½:

> I'm thinking of giving another try to writing a plotting library for D.  I'm trying to decide what GUI library to use.  Here's what's important to me, in order of importance.  Someone who's more familiar with the GUI library situation than I am please make a recommendation.
> 
> 1.  Good D2 support.  I don't want something that's going to take forever to be usable in D2 even after the spec is stable.
> 
> 2.  Performance.  If a scatter plot with 50,000 points takes a few seconds to redraw when the window is resized, it's too slow.  I'm frankly sick of using slow plotting libraries in other languages.
> 
> 3.  Licensing.  I prefer something permissive like BSD or Boost.  LGPL is acceptable, though annoying and sometimes ambiguous.  If it's GPL I just plain won't use it because I want the license to the plotting library to be reasonably permissive.
> 
> 4.  Simplicity of API.  I don't want a library that requires tons of boilerplate to do simple things.
> 
> 5.  Platform support.  Windows XP, Vista and 7 and x86 Linux are a must.  I don't care so much about macs or some of the more esoteric platforms, or about ancient versions of Windows.
> 
> What isn't very important:
> 
> 1.  Lots of features/flexibility.  I'm thinking the plotting lib will be a minimalist library, focused on "just working", simplicity of API and performance rather than on lots of bells and whistles and extensibility. Therefore, I don't need lots of bells and whistles in my GUI library.
> 
> 2.  Native look and feel.  IMHO this is very overrated.  I've never found that a Java-ish or GTK-ish or whatever look and feel instead of a native Win32 look and feel got in the way of me using a program effectively.
> 
> 3.  Stable ABI.  The plotting library will never have a stable ABI, only a stable source-level API.  Most of the API will probably be templates anyhow. Therefore, I don't care if the GUI library has no stable ABI, only a stable source-level API.

or ports java7's swing 2.0    :-)

On 12/12/2009 06:10, dsimcha wrote:
> I'm thinking of giving another try to writing a plotting library for D.  I'm
> trying to decide what GUI library to use.  Here's what's important to me, in
> order of importance.  Someone who's more familiar with the GUI library
> situation than I am please make a recommendation.
>
> 1.  Lots of features/flexibility.  I'm thinking the plotting lib will be a
> minimalist library, focused on "just working", simplicity of API and
> performance rather than on lots of bells and whistles and extensibility.
> Therefore, I don't need lots of bells and whistles in my GUI library.


I think Ben Hinkle's MinWin could be interesting.
+ supports win/linux, is public domain (afaik), is lightweight.
- is pre D 1.0
you will find it somewhere on dsource. wait...  : http://www.dsource.org/projects/minwin

>
> 2.  Native look and feel.  IMHO this is very overrated.  I've never found that
> a Java-ish or GTK-ish or whatever look and feel instead of a native Win32 look
> and feel got in the way of me using a program effectively.
>

Guess you don't have to sell software :) we have to spend 2000$ a year just for GUI Toolkits.
Björn

dsimcha:

> I'm thinking of giving another try to writing a plotting library for D.

I like what you have written.
I suggest this as the rendering layer, because it's beyond awesome (used in MatPlotLib too):
http://www.antigrain.com/

Bye,
bearophile

On Sat, Dec 12, 2009 at 5:05 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> dsimcha:
>
>> I'm thinking of giving another try to writing a plotting library for D.
>
> I like what you have written.
> I suggest this as the rendering layer, because it's beyond awesome (used in MatPlotLib too):
> http://www.antigrain.com/

AGG's renderings do look nice.  But it will require significant effort to use, as it is written using highly templated C++, and no one has attempted a port to D at this point.  Also it doesn't do windowing, so you still need to solve the window creation thing (but you could use something simple like SDL in Derelict for that.)

However, assuming QtD includes QGraphicsView (http://doc.trolltech.com/4.5/qgraphicsview.html) I think that would be the least-effort route to make a plotting tool with cross-platform antialiased graphics.  And it gives you plenty of head-room to grow if your charter grows beyond the initial idea of a bare-bones plotting tool.

--bb

Sat, 12 Dec 2009 10:19:14 +0100, BLS wrote:

> Guess you don't have to sell software :) we have to spend 2000$ a year just for GUI Toolkits.

A colleague's company was previously using the expensive commercial Qt. Now they use the lgpl licensed one and are still making money. They also use gpl/lgpl licensed components for web 2.0 GUIs. In cloud environments you only need to reveal your closed sources if you're using AGPL. Feels weird that someone can't accept lgpl for commercial use.

Sat, 12 Dec 2009 05:10:24 +0000, dsimcha wrote:

> 2.  Native look and feel.  IMHO this is very overrated.  I've never found that a Java-ish or GTK-ish or whatever look and feel instead of a native Win32 look and feel got in the way of me using a program effectively.

The win32 look and feel doesn't look native on linux/mac/solaris.

== Quote from retard (re@tard.com.invalid)'s article
> Sat, 12 Dec 2009 05:10:24 +0000, dsimcha wrote:
> > 2.  Native look and feel.  IMHO this is very overrated.  I've never found that a Java-ish or GTK-ish or whatever look and feel instead of a native Win32 look and feel got in the way of me using a program effectively.
> The win32 look and feel doesn't look native on linux/mac/solaris.

Right, the implication here was that I mostly use Windows and I've never really cared if an application I use has a GTK-ish or Swing-ish or whatever look and feel, as long as the application is well-coded, responsive and does what I need. I'm speaking purely from personal opinion/experience here, but I don't understand why people care so much about platform-native look and feel as long as it works and is usable.

Sat, 12 Dec 2009 16:13:39 +0000, dsimcha wrote:

> == Quote from retard (re@tard.com.invalid)'s article
>> Sat, 12 Dec 2009 05:10:24 +0000, dsimcha wrote:
>> > 2.  Native look and feel.  IMHO this is very overrated.  I've never found that a Java-ish or GTK-ish or whatever look and feel instead of a native Win32 look and feel got in the way of me using a program effectively.
>> The win32 look and feel doesn't look native on linux/mac/solaris.
> 
> Right, the implication here was that I mostly use Windows and I've never really cared if an application I use has a GTK-ish or Swing-ish or whatever look and feel, as long as the application is well-coded, responsive and does what I need. I'm speaking purely from personal opinion/experience here, but I don't understand why people care so much about platform-native look and feel as long as it works and is usable.

Well programs tend to be cross-platform these days. More like that in *nix world, since the development toolchain is highly portable. I daily use programs written by authors who favor Linux, *BSD, MacOS X, and Windows. If everyone just made their programs use the theme and conventions of their favorite OS, I would have to deal with 10+ different GUIs in daily work.

I currently use Swing apps, AWT apps, SWT apps, GTK+ 2 apps, Qt 3 and Qt 4 apps, TCL/TK apps, run some games via wine (win32 gui), and some applications even use the old legacy unix gui toolkits. Then some apps like google chrome have their own kind of look and feel. Web applications have proprietary custom look and feel. This is pretty confusing to me, at least.