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

Right now we are working on a next QtD version. We dropped support for D1, it is D2 only. I believe Qt suits all your requirements very well. It's performant - we try to emulate as many C++ types using D structs as possible, for drawing purposes. So types like QPoint - are D structs and for drawing lines you can pass D array directly. No perfromance hit. But of course we cannot avoid all of them, it is still a binding. Regarding the license, Qt itself is LGPLed, QtD is boost. you don't have to put any attribution.
About stability of APIs - Qt4 is stable within the major version. At the moment we are working on signals/slots implementation. It is mostly complete, but syntax may change. It will hopefully change once and stay forever.

I would say that QtD is in the state close to that of D2, almost there, but not quite ready yet. But we intend to release the next version, which will be ready to use earlier than D2 anyway, I would say within a month.

As for plotting, there is a nice Qt library called Qwt. We can include bindings for it as a part of QtD, but it requires some work. But that's not necessary, you can use pure Qt to write your own widgets, you can even port Qwt code to D.

Thanks,

Eldar.

Eldar Insafutdinov wrote:
> Right now we are working on a next QtD version. We dropped support
> for D1, it is D2 only. I believe Qt suits all your requirements very
> well. It's performant - we try to emulate as many C++ types using D
> structs as possible, for drawing purposes. So types like QPoint - are
> D structs and for drawing lines you can pass D array directly. No
> perfromance hit. But of course we cannot avoid all of them, it is
> still a binding. Regarding the license, Qt itself is LGPLed, QtD is
> boost. you don't have to put any attribution. About stability of APIs
> - Qt4 is stable within the major version. At the moment we are
> working on signals/slots implementation. It is mostly complete, but
> syntax may change. It will hopefully change once and stay forever.
> 
> I would say that QtD is in the state close to that of D2, almost
> there, but not quite ready yet. But we intend to release the next
> version, which will be ready to use earlier than D2 anyway, I would
> say within a month.

I salute the decision of going with D2, as well as that of using the Boost license. If there is anything in the language that prevents you from getting things done, please let us know. The availability of QtD concurrently with that of D2 will hopefully push both forward.

Andrei

On 12/12/2009 16:59, retard wrote:
> 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.

We/I have no pb with lpgl'ed software. But :
Fact 1 :none of the open source GUI solutions are good enough. (for what we need) - especially the grid controls/widgets are completely insufficient. Not to talk abpout Gui support for multilingual/national apps.

Fact 2 : ~95 percent of our customers are using MS products. (OS and infrastructure) so platform independence is a minor issue.

Fact 3: Since (we think) our products are mission critical we need 24/7 long term support. -not always given in open source projects.

Björn

On 12/12/2009 17:53, Andrei Alexandrescu wrote:
> I salute the decision of going with D2, as well as that of using the
> Boost license. If there is anything in the language that prevents you
> from getting things done, please let us know. The availability of QtD
> concurrently with that of D2 will hopefully push both forward.
>
> Andrei

I think allowing multiple
"alias this" (instead of interfaces and mixins)
will make sense in order to make the QT-Designer as well as as the web kit usable for D.
just my 2 cents.
bjoern

Sat, 12 Dec 2009 11:53:50 -0500, Andrei Alexandrescu wrote:

> Eldar Insafutdinov wrote:
>> Right now we are working on a next QtD version. We dropped support for D1, it is D2 only. I believe Qt suits all your requirements very well. It's performant - we try to emulate as many C++ types using D structs as possible, for drawing purposes. So types like QPoint - are D structs and for drawing lines you can pass D array directly. No perfromance hit. But of course we cannot avoid all of them, it is still a binding. Regarding the license, Qt itself is LGPLed, QtD is boost. you don't have to put any attribution. About stability of APIs - Qt4 is stable within the major version. At the moment we are working on signals/slots implementation. It is mostly complete, but syntax may change. It will hopefully change once and stay forever.
>> 
>> I would say that QtD is in the state close to that of D2, almost there, but not quite ready yet. But we intend to release the next version, which will be ready to use earlier than D2 anyway, I would say within a month.
> 
> I salute the decision of going with D2, as well as that of using the Boost license. If there is anything in the language that prevents you from getting things done, please let us know. The availability of QtD concurrently with that of D2 will hopefully push both forward.

I don't get why Boost license should be used. It's just confusing to have yet another free for all license as it basically promises the same things as the 2-clause BSD or MIT license. The only difference I see is that the author of a Boost licensed software publicly admits that he is a Boost fanboy and thinks the license somehow got better after his personal deities rewrote it from scratch with NIH mentality.

"dsimcha" <dsimcha@yahoo.com> wrote in message news:hg0ffj$2baj$1@digitalmars.com...
> == 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.

For me, it's things like this (in no particular order):

- Non-native controls flat-out ignore my system settings. Doesn't matter if it causes practical problems or not, there is absolutely NO excuse for that, period.

- It implies a certain "taking over the user's system", just like a website deciding on it's own that it wants to open things in a new browser window. These sorts of behaviors are insulting.

- If every program insists on having it's own different look, then my system suddenly looks like a horrid mess. Purely an aesthetic issue, yes, but #1, it's my own fucking system, so *I* and I alone should be able to have total control over how it looks (if it wants to allow alternate skins, then fine, but make that shit an *option*, not the default and *certainly* not the only choice) and #2, I *like* the look of the theme I've set up.

- Non-native stuff often includes completely unnecessary steps backwards.
For example:
   - On windows, normal "greyed-out" and separator lines have a 3d-ish
effect that is perfectly legible on any color scheme. But most non-native
stuff uses a single-color grey instead that becomes nearly-illegible, or
even downright invisible, on many color schemes, including my own.
   - GTK apps are ridiculously chunky and waste an enormous amount of screen
real-estate. Which *is* a practical concern.
   - Many GTK apps use the absolute *worst* and most impractical file dialog
boxes I've seen in over 15 years. This is never an issue with native apps.

== Quote from retard (re@tard.com.invalid)'s article
> Sat, 12 Dec 2009 11:53:50 -0500, Andrei Alexandrescu wrote:
> > Eldar Insafutdinov wrote:
> >> Right now we are working on a next QtD version. We dropped support for D1, it is D2 only. I believe Qt suits all your requirements very well. It's performant - we try to emulate as many C++ types using D structs as possible, for drawing purposes. So types like QPoint - are D structs and for drawing lines you can pass D array directly. No perfromance hit. But of course we cannot avoid all of them, it is still a binding. Regarding the license, Qt itself is LGPLed, QtD is boost. you don't have to put any attribution. About stability of APIs - Qt4 is stable within the major version. At the moment we are working on signals/slots implementation. It is mostly complete, but syntax may change. It will hopefully change once and stay forever.
> >>
> >> I would say that QtD is in the state close to that of D2, almost there, but not quite ready yet. But we intend to release the next version, which will be ready to use earlier than D2 anyway, I would say within a month.
> >
> > I salute the decision of going with D2, as well as that of using the Boost license. If there is anything in the language that prevents you from getting things done, please let us know. The availability of QtD concurrently with that of D2 will hopefully push both forward.
> I don't get why Boost license should be used. It's just confusing to have yet another free for all license as it basically promises the same things as the 2-clause BSD or MIT license. The only difference I see is that the author of a Boost licensed software publicly admits that he is a Boost fanboy and thinks the license somehow got better after his personal deities rewrote it from scratch with NIH mentality.

Because the Boost license doesn't require attribution for works only distributed in binary form.

"dsimcha" <dsimcha@yahoo.com> wrote in message news:hg0kq2$2ktg$1@digitalmars.com...
> == Quote from retard (re@tard.com.invalid)'s article
>> Sat, 12 Dec 2009 11:53:50 -0500, Andrei Alexandrescu wrote:
>> > Eldar Insafutdinov wrote:
>> >> Right now we are working on a next QtD version. We dropped support for
>> >> D1, it is D2 only. I believe Qt suits all your requirements very well.
>> >> It's performant - we try to emulate as many C++ types using D structs
>> >> as possible, for drawing purposes. So types like QPoint - are D
>> >> structs
>> >> and for drawing lines you can pass D array directly. No perfromance
>> >> hit. But of course we cannot avoid all of them, it is still a binding.
>> >> Regarding the license, Qt itself is LGPLed, QtD is boost. you don't
>> >> have to put any attribution. About stability of APIs - Qt4 is stable
>> >> within the major version. At the moment we are working on
>> >> signals/slots
>> >> implementation. It is mostly complete, but syntax may change. It will
>> >> hopefully change once and stay forever.
>> >>
>> >> I would say that QtD is in the state close to that of D2, almost
>> >> there,
>> >> but not quite ready yet. But we intend to release the next version,
>> >> which will be ready to use earlier than D2 anyway, I would say within
>> >> a
>> >> month.
>> >
>> > I salute the decision of going with D2, as well as that of using the Boost license. If there is anything in the language that prevents you from getting things done, please let us know. The availability of QtD concurrently with that of D2 will hopefully push both forward.
>> I don't get why Boost license should be used. It's just confusing to have yet another free for all license as it basically promises the same things as the 2-clause BSD or MIT license. The only difference I see is that the author of a Boost licensed software publicly admits that he is a Boost fanboy and thinks the license somehow got better after his personal deities rewrote it from scratch with NIH mentality.
>
> Because the Boost license doesn't require attribution for works only
> distributed
> in binary form.

The zlib license, then.

Sat, 12 Dec 2009 17:44:34 +0000, dsimcha wrote:

> == Quote from retard (re@tard.com.invalid)'s article
>> Sat, 12 Dec 2009 11:53:50 -0500, Andrei Alexandrescu wrote:
>> > Eldar Insafutdinov wrote:
>> >> Right now we are working on a next QtD version. We dropped support for D1, it is D2 only. I believe Qt suits all your requirements very well. It's performant - we try to emulate as many C++ types using D structs as possible, for drawing purposes. So types like QPoint - are D structs and for drawing lines you can pass D array directly. No perfromance hit. But of course we cannot avoid all of them, it is still a binding. Regarding the license, Qt itself is LGPLed, QtD is boost. you don't have to put any attribution. About stability of APIs - Qt4 is stable within the major version. At the moment we are working on signals/slots implementation. It is mostly complete, but syntax may change. It will hopefully change once and stay forever.
>> >>
>> >> I would say that QtD is in the state close to that of D2, almost there, but not quite ready yet. But we intend to release the next version, which will be ready to use earlier than D2 anyway, I would say within a month.
>> >
>> > I salute the decision of going with D2, as well as that of using the Boost license. If there is anything in the language that prevents you from getting things done, please let us know. The availability of QtD concurrently with that of D2 will hopefully push both forward.
>> I don't get why Boost license should be used. It's just confusing to have yet another free for all license as it basically promises the same things as the 2-clause BSD or MIT license. The only difference I see is that the author of a Boost licensed software publicly admits that he is a Boost fanboy and thinks the license somehow got better after his personal deities rewrote it from scratch with NIH mentality.
> 
> Because the Boost license doesn't require attribution for works only distributed in binary form.

Isn't that kind of insulting towards the original author -- "Your work wasn't worth a crap. I'll take full credit. You get nothing, community gets nothing." Encouraging this kind of licenses seems really weird. Ah yes, zlib was also mentioned - so does one get any advantages when converting an existing D project from zlib/libpng license to boost license?

On 12/12/2009 18:44, dsimcha wrote:
> Because the Boost license doesn't require attribution for works only distributed
> in binary form.

All these kitchen sink license issues are monkey buisiness.
If you don't care : make it public domain.
if you want to share : make it GPL 3
if you want to make money : make it close source.
period.