www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D2 GUI Libs

reply dsimcha <dsimcha yahoo.com> writes:
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.
Dec 11 2009
next sibling parent dolive <dolive89 sina.com> writes:
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
Dec 11 2009
prev sibling next sibling parent dolive <dolive89 sina.com> writes:
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 :-)
Dec 11 2009
prev sibling next sibling parent reply BLS <windevguy hotmail.de> writes:
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
Dec 12 2009
parent reply retard <re tard.com.invalid> writes:
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.
Dec 12 2009
parent BLS <windevguy hotmail.de> writes:
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
Dec 12 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Dec 12 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Dec 12 2009
parent "Bob Jones" <me not.com> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.593.1260627949.20261.digitalmars-d puremagic.com...
 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.)

Another option is... http://mlab.taik.fi/~kkallio/antialiasing/ It took me about 3 days to write and debug my own implementation. I only did even/odd 8x sampling, but it's simple and fast. My C++ rasterizer (just the bit that converts polygons into scanlines) is only 550 lines of code.
Dec 13 2009
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
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.
Dec 12 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.


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.
Dec 12 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.


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.
Dec 12 2009
parent reply Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:

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

I like how gimp dialog box provides mruds, which is not done by virtually any other windows application, this is extremely useful, which is a practical concern.
Dec 14 2009
parent "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:hg5bnt$1105$1 digitalmars.com...
 Nick Sabalausky Wrote:

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

I like how gimp dialog box provides mruds, which is not done by virtually any other windows application, this is extremely useful, which is a practical concern.

(I assume you mean "most recently used (documents|directories)") That's something I think is much better handled by something other than the individual application. Something like this would be much better: Have a system where it's possible to install add-ons to the system dialog boxes. There would be a utility (accessible via an app and via an API) to manage these add-ons which would allow the user (or an application) to enable/disable/tweak these add-ons on both a universal level and override any of the settings on an application-by-application basis.
Dec 14 2009
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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.


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.

I think native look and feel is a lot more important in, say, a web browser or a word processor. I don't care so much about which GUI toolkits Gnuplot or Mathematica use... -Lars
Dec 14 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
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.


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.
Dec 12 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Dec 14, 2009 at 2:24 AM, Lars T. Kyllingstad
<public kyllingen.nospamnet> wrote:
 dsimcha wrote:
 =3D=3D Quote from retard (re tard.com.invalid)'s article
 Sat, 12 Dec 2009 05:10:24 +0000, dsimcha wrote:
 2. =A0Native look and feel. =A0IMHO this is very overrated. =A0I've ne=




 found that a Java-ish or GTK-ish or whatever look and feel instead of =




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


 and
 feel, as long as the application is well-coded, responsive and does what=


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


 works
 and is usable.

I think native look and feel is a lot more important in, say, a web brows=

 or a word processor. I don't care so much about which GUI toolkits Gnuplo=

 or Mathematica use...

Non-native file dialogs which are bizarro (like gtk) or underpowered (like some Java ones) are the main thing that drive me crazy. There's a lot of nice stuff built into the native Windows file dialogs. It's very annoying when some non-native app takes all that away. Also there are standard key-bindings. Though probably any non-native app could be made to follow the platform conventions, the chances that a non-native LAF app will fail here are generally greater. On Windows these are things like Alt-F4 to close app. Ctrl-F4 or Ctrl-W to close a sub-window or document. Ctrl-Tab to navigate tabs of a notebook-like widget, etc. Also the way Alt works on Windows for controlling menus is something I've seen non-native apps futzing. So basically I don't care much about non-native *look*, it's the non-native *feel* I find annoying. --bb
Dec 14 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Dec 12 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 12 2009
next sibling parent BLS <windevguy hotmail.de> writes:
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
Dec 12 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.

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.
Dec 12 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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.

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.
Dec 12 2009
prev sibling next sibling parent reply BLS <windevguy hotmail.de> writes:
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.
Dec 12 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"BLS" <windevguy hotmail.de> wrote in message 
news:hg0or1$2rtu$1 digitalmars.com...
 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.

I'm really tired of public domain constantly being tossed around as if it were actually a reasonable option: 1. If you put someting in PD, you're no longer legally allowed to claim that you actually wrote it (leave it to a government to try to redefine reality like that...). In other words, you're not allowed to state an actual fact about it. 2. Different countries define public domain differently, some countries don't define it, and others don't even have a concept of public domain at all. Adam also said there's a liability issue, but (IANAL) that would surprise me because AIUI, public domain is all about severing *all* ties between an author and their work. But then again, that's probably just one of those things that differs by country. The thing about zlib (or something like beerware) is that it's basically a version of public domain that *isn't* total crap.
 if you want to share : make it GPL 3

That's just BS. It's more like this: If you want to share *only* with people who, #1 also want to share everything they do with it, *and* #2 don't mind dealing with a fifty-foot wall of legalese gibberish that's completely impenetrable without shelling out bucks for a lawyer that'll probably cost them more than if you had just charged a basic fee in the first place: Make it GPL. If you *just simply want to share*: Make it zlib, or maybe beerware or something like that.
 if you want to make money : make it close source.
 period.
 

Dec 12 2009
parent reply BLS <windevguy hotmail.de> writes:
On 12/12/2009 21:14, Nick Sabalausky wrote:
 "BLS"<windevguy hotmail.de>  wrote in message
 news:hg0or1$2rtu$1 digitalmars.com...
 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.

I'm really tired of public domain constantly being tossed around as if it were actually a reasonable option: 1. If you put someting in PD, you're no longer legally allowed to claim that you actually wrote it (leave it to a government to try to redefine reality like that...). In other words, you're not allowed to state an actual fact about it. 2. Different countries define public domain differently, some countries don't define it, and others don't even have a concept of public domain at all.

That's why I wrote : "If you don't care.."
 Adam also said there's a liability issue, but (IANAL) that would surprise me
 because AIUI, public domain is all about severing *all* ties between an
 author and their work. But then again, that's probably just one of those
 things that differs by country.

Bureaucrat nonsense. or in my words : fuck the duck. even if this is true , who cares ? Do you think you will find a lawyer who is willing to kick an ass because he/she is giving away an intellectual property / programming pearl,he/she invented, for free ? anyway, it seems to me that we have a lot of semi professional lawyers on board and I am not sure how much this helps. ( A professional one is already a disaster...) KISS, Bjoern
Dec 12 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from BLS (windevguy hotmail.de)'s article

true , who cares ? Do you think you will find a lawyer who is willing to kick an ass because he/she is giving away an intellectual property / programming pearl,he/she invented, for free ? anyway, it seems to me that we have a lot of semi professional lawyers on board and I am not sure how much this helps. ( A professional one is already a disaster...) KISS, Bjoern

Well, I was going to compare lawyers to whores, but that would be an insult to the whore profession.
Dec 12 2009
parent BLS <windevguy hotmail.de> writes:
On 12/12/2009 23:44, dsimcha wrote:
 Well, I was going to compare lawyers to whores, but that would be an insult to
the
 whore profession.

very good point. -> true since I got your attention.. I thing it is time to start a std.container discussion. Your AA lib call is not making much progress and I further think Steven is also waiting for some D2 decisions. guess what I want to say is that we need some clarification about ranges and opXXX FI your AA implementation is using ranges as formalism. In other words you implement them as part of a node structure. Andrei is defining them as Interfaces. Steven also has a different view on how to implement collection ( using a struct pair) instead of K,V. using kinda Iterators.. Almost your questions : allow custom allocators ? ref or value semantics specialized quantity allocators for low/high capacity containers. what I really like in Steven's implementation is support replaceable data structures/algorithms.. AAs could be based on RB trees as well as on SkipList.. but : Is this a good thing ? Is there a way to decide at runtime ? -- In case that we choose classes (implementing Tange Interfaces) it would be (IMO) a good start to create the class-interface hierarchy Andrei has an eye on Gobo Eiffel but a discussion would make sense. a lot of questions, hope YOU will create a new thread.
Dec 12 2009
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
retard wrote:

 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.

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?

Some corporations won't use licenses which require attribution (and even will rather pay for code instead), so they will automatically drop D as a language if such a license is adopted. If you want to know more about the boost license, this page has the background on it including the rationale and history: http://www.boost.org/users/license.html
Dec 12 2009
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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. Andrei

Thanks for cooperation. I don't want to sound like I've given the right to ask for features, because I am working on a particular D project. But at the same time, indeed, while working on this project I found many things that I would like to be improved. Here are some of them: 1) You may know the concept of signals and slots in Qt. Consider the following snippet: class Test : QObject { mixin Signal!("signal_1(string)"); mixin Slot!("slot_1(string str)"); void slot_1(string str) { writefln("slot_1 invoked with ~ " str); } mixin Q_OBJECT; } In Qt objects, that inherit from QObject are capable of having signals and slots and participate in connections. In the current scheme mixins of Signal and Slot template mix some static information into the class. The class is then scanned when Q_OBJECT template is mixed in and the proper meta-information is generated to register signals and slots in the Qt type system. As you see, this declaration is a bit ugly. In particular defining a slot requires to duplicate its signature in a mixin. What would really be awesome is a mechanism allowing something like: Slot void slot_1(string str) { writefln("slot_1 invoked with " ~ str); } I.e we need annotations. But I am not sure how this will work. One of the possible solutions will be that Slot expands into mixin Slot!(symbol, AnnotationArg1, ...). But I have to say, that expanding annotations into mixins might not be a good idea. Annotations could rather be implemented by aggregating the data with symbols instead. I think it will be more clean than the current scheme we chose with mixing in and scanning data. Instead you have some data aggregated with declarations. Using compile time reflection you iterate over the symbols, look for annotations, extract them and do whatever you want with it. Say if we introduce traits(getAnnotations, symbol) feature and it will return a construct like StaticTuple!(SealedTuple!("annotationName", AnnotationArg1, ...), ...); it will be sufficient. We should discuss it more anyway. 2) Second problem in this declaration is that in order for Q_OBJECT template to see all signal and slot declaration you have to put the mixin after all of them, like in example. This is absolutely a stupid requirement. Again it could be solved either by annotations: Q_OBJECT class Test : QObject { ... } which will again expand into a mixin in the class body after all of the declarations, or by the feature you suggested a while ago - mixin (Derived), which will mix in some stuff to all sub-classes of QObject automatically. 3) To continue the first paragraph signals should also get some love. If we have this for slots: Slot void slot_1(string str) { ... } I would also like to have something like: Signal void signal_1(); What it will effectively means, is that we are declaring a method without a body and aggregate some meta data with it using annotation. The body for the signal instead of being generated by the mixin Signal!(...) like in the first snippet, will be generated at the very end by mixin Q_OBJECT (or with a mixin Derived) Essentially we should allow separating function declaration and definition to allow that, currently dmd just asserts trying to compile this: class Test { void foo(); void foo() {} } So the final refined declaration of a class with a signal and a slot from the first snippet using proper annotations, mixin Derived in the base class and allowing for separating function declaration and definition will look like: class Test : QObject { Signal void signal_1(string); Slot void slot_1(string str) { writefln("slot_1 invoked with " ~ str); } } Much nicer, isn't it? 4) __traits should access the data mixed in by template mixins. Otherwise we have to use dirty template trickery. 5) As QtD uses templates extensively, it would be really helpful if the compiler gave better error messages about template instantiation errors. Specifically, static assert(false, ) is often used to give the user a message about the error but it is sometimes very hard to find the place of outer instantiation. Propagating the FILE_ and __LINE__ to nested instantiations is impractical. There has been this patch by Don for a long time that fixes the 'static assert' issue: http://d.puremagic.com/issues/show_bug.cgi?id=2816. We'd really like to have it applied. See also http://d.puremagic.com/issues/show_bug.cgi?id=2902, http://d.puremagic.com/issues/show_bug.cgi?id=2510. 6) Various, various compiler bugs. I'm not joking here, I hit dmd bugs every single day I work on qtd. It makes it very difficult to cut down to sensible testcases, because of the size of the library. I filed some bugs, I used all my votes in bugzilla, but neither of those got any update within last 2 months. That's a pity. I am sure many other people have similar experience. The main one is probably forward references bug. That's why I have to use patched version of dmd (done not by me). Work on it is still in progress, and when the author of the patches finishes it and submits them to the bugzilla, we would need apply them somehow, as otherwise official dmd will not compile QtD.
Dec 13 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Eldar Insafutdinov" <e.insafutdinov gmail.com> wrote in message 
news:hg2p87$2ttj$1 digitalmars.com...
 1) You may know the concept of signals and slots in Qt. Consider the 
 following snippet:

 class Test : QObject
 {
    mixin Signal!("signal_1(string)");

    mixin Slot!("slot_1(string str)");
    void slot_1(string str)
    {
        writefln("slot_1 invoked with ~ " str);
    }

    mixin Q_OBJECT;
 }

 In Qt objects, that inherit from QObject are capable of having signals and 
 slots and participate in connections. In the current scheme mixins of 
 Signal and Slot template mix some static information into the class. The 
 class is then scanned when Q_OBJECT template is mixed in and the proper 
 meta-information is generated to register signals and slots in the Qt type 
 system.
 As you see, this declaration is a bit ugly. In particular defining a slot 
 requires to duplicate its signature in a mixin. What would really be 
 awesome is a mechanism allowing something like:

     Slot
    void slot_1(string str)
    {
        writefln("slot_1 invoked with " ~ str);
    }
 I.e we need annotations. But I am not sure how this will work. One of the 
 possible solutions will be that  Slot expands into mixin Slot!(symbol, 
 AnnotationArg1, ...).

Try string mixins, something like this: 1. Rename Slot to _Slot. 2. Do this: template Slot(string decl, string body) { const string Slot = " mixin Slot!("~decl.stringof~"); void slot_1(string str) { "~body.stringof~" } "; } class Test : QObject { mixin Signal!("signal_1(string)"); mixin( Slot!("slot_1(string str)", q{ writefln("slot_1 invoked with ~ " str); }) ); mixin Q_OBJECT; }
Dec 13 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hg394f$mr1$1 digitalmars.com...
 "Eldar Insafutdinov" <e.insafutdinov gmail.com> wrote in message 
 news:hg2p87$2ttj$1 digitalmars.com...
 1) You may know the concept of signals and slots in Qt. Consider the 
 following snippet:

 class Test : QObject
 {
    mixin Signal!("signal_1(string)");

    mixin Slot!("slot_1(string str)");
    void slot_1(string str)
    {
        writefln("slot_1 invoked with ~ " str);
    }

    mixin Q_OBJECT;
 }

 In Qt objects, that inherit from QObject are capable of having signals 
 and slots and participate in connections. In the current scheme mixins of 
 Signal and Slot template mix some static information into the class. The 
 class is then scanned when Q_OBJECT template is mixed in and the proper 
 meta-information is generated to register signals and slots in the Qt 
 type system.
 As you see, this declaration is a bit ugly. In particular defining a slot 
 requires to duplicate its signature in a mixin. What would really be 
 awesome is a mechanism allowing something like:

     Slot
    void slot_1(string str)
    {
        writefln("slot_1 invoked with " ~ str);
    }
 I.e we need annotations. But I am not sure how this will work. One of the 
 possible solutions will be that  Slot expands into mixin Slot!(symbol, 
 AnnotationArg1, ...).


Oops, slight typo:
 Try string mixins, something like this:

 1. Rename Slot to _Slot.

 2. Do this:

// Fixed: template Slot(string decl, string body) { const string Slot = " mixin _Slot!("~decl.stringof~"); void slot_1(string str) { "~body.stringof~" } "; }
 class Test : QObject
 {
    mixin Signal!("signal_1(string)");

    mixin( Slot!("slot_1(string str)", q{
        writefln("slot_1 invoked with ~ " str);
    }) );

   mixin Q_OBJECT;
 }

 

Dec 13 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Nick Sabalausky Wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:hg394f$mr1$1 digitalmars.com...
 "Eldar Insafutdinov" <e.insafutdinov gmail.com> wrote in message 
 news:hg2p87$2ttj$1 digitalmars.com...
 1) You may know the concept of signals and slots in Qt. Consider the 
 following snippet:

 class Test : QObject
 {
    mixin Signal!("signal_1(string)");

    mixin Slot!("slot_1(string str)");
    void slot_1(string str)
    {
        writefln("slot_1 invoked with ~ " str);
    }

    mixin Q_OBJECT;
 }

 In Qt objects, that inherit from QObject are capable of having signals 
 and slots and participate in connections. In the current scheme mixins of 
 Signal and Slot template mix some static information into the class. The 
 class is then scanned when Q_OBJECT template is mixed in and the proper 
 meta-information is generated to register signals and slots in the Qt 
 type system.
 As you see, this declaration is a bit ugly. In particular defining a slot 
 requires to duplicate its signature in a mixin. What would really be 
 awesome is a mechanism allowing something like:

     Slot
    void slot_1(string str)
    {
        writefln("slot_1 invoked with " ~ str);
    }
 I.e we need annotations. But I am not sure how this will work. One of the 
 possible solutions will be that  Slot expands into mixin Slot!(symbol, 
 AnnotationArg1, ...).


Oops, slight typo:
 Try string mixins, something like this:

 1. Rename Slot to _Slot.

 2. Do this:

// Fixed: template Slot(string decl, string body) { const string Slot = " mixin _Slot!("~decl.stringof~"); void slot_1(string str) { "~body.stringof~" } "; }
 class Test : QObject
 {
    mixin Signal!("signal_1(string)");

    mixin( Slot!("slot_1(string str)", q{
        writefln("slot_1 invoked with ~ " str);
    }) );

   mixin Q_OBJECT;
 }

 


Thank you for suggestion, but while reducing redundancy it became even uglier! I'll better stay with the current syntax.
Dec 13 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Eldar Insafutdinov" <e.insafutdinov gmail.com> wrote in message 
news:hg3g6u$11so$1 digitalmars.com...
 Nick Sabalausky Wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:hg394f$mr1$1 digitalmars.com...
 "Eldar Insafutdinov" <e.insafutdinov gmail.com> wrote in message
 news:hg2p87$2ttj$1 digitalmars.com...
 1) You may know the concept of signals and slots in Qt. Consider the
 following snippet:

 class Test : QObject
 {
    mixin Signal!("signal_1(string)");

    mixin Slot!("slot_1(string str)");
    void slot_1(string str)
    {
        writefln("slot_1 invoked with ~ " str);
    }

    mixin Q_OBJECT;
 }

 In Qt objects, that inherit from QObject are capable of having signals
 and slots and participate in connections. In the current scheme mixins 
 of
 Signal and Slot template mix some static information into the class. 
 The
 class is then scanned when Q_OBJECT template is mixed in and the 
 proper
 meta-information is generated to register signals and slots in the Qt
 type system.
 As you see, this declaration is a bit ugly. In particular defining a 
 slot
 requires to duplicate its signature in a mixin. What would really be
 awesome is a mechanism allowing something like:

     Slot
    void slot_1(string str)
    {
        writefln("slot_1 invoked with " ~ str);
    }
 I.e we need annotations. But I am not sure how this will work. One of 
 the
 possible solutions will be that  Slot expands into mixin Slot!(symbol,
 AnnotationArg1, ...).


Oops, slight typo:
 Try string mixins, something like this:

 1. Rename Slot to _Slot.

 2. Do this:

// Fixed: template Slot(string decl, string body) { const string Slot = " mixin _Slot!("~decl.stringof~"); void slot_1(string str) { "~body.stringof~" } "; }
 class Test : QObject
 {
    mixin Signal!("signal_1(string)");

    mixin( Slot!("slot_1(string str)", q{
        writefln("slot_1 invoked with ~ " str);
    }) );

   mixin Q_OBJECT;
 }


Thank you for suggestion, but while reducing redundancy it became even uglier! I'll better stay with the current syntax.

Yea, string mixins, powerful as they may be, are a bit of a poor-man's annotations.
Dec 13 2009
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 12/13/09 20:44, Eldar Insafutdinov wrote:
 Nick Sabalausky Wrote:

 "Nick Sabalausky"<a a.a>  wrote in message
 news:hg394f$mr1$1 digitalmars.com...
 "Eldar Insafutdinov"<e.insafutdinov gmail.com>  wrote in message
 news:hg2p87$2ttj$1 digitalmars.com...
 1) You may know the concept of signals and slots in Qt. Consider the
 following snippet:

 class Test : QObject
 {
     mixin Signal!("signal_1(string)");

     mixin Slot!("slot_1(string str)");
     void slot_1(string str)
     {
         writefln("slot_1 invoked with ~ " str);
     }

     mixin Q_OBJECT;
 }

 In Qt objects, that inherit from QObject are capable of having signals
 and slots and participate in connections. In the current scheme mixins of
 Signal and Slot template mix some static information into the class. The
 class is then scanned when Q_OBJECT template is mixed in and the proper
 meta-information is generated to register signals and slots in the Qt
 type system.
 As you see, this declaration is a bit ugly. In particular defining a slot
 requires to duplicate its signature in a mixin. What would really be
 awesome is a mechanism allowing something like:

      Slot
     void slot_1(string str)
     {
         writefln("slot_1 invoked with " ~ str);
     }
 I.e we need annotations. But I am not sure how this will work. One of the
 possible solutions will be that  Slot expands into mixin Slot!(symbol,
 AnnotationArg1, ...).


Oops, slight typo:
 Try string mixins, something like this:

 1. Rename Slot to _Slot.

 2. Do this:

// Fixed: template Slot(string decl, string body) { const string Slot = " mixin _Slot!("~decl.stringof~"); void slot_1(string str) { "~body.stringof~" } "; }
 class Test : QObject
 {
     mixin Signal!("signal_1(string)");

     mixin( Slot!("slot_1(string str)", q{
         writefln("slot_1 invoked with ~ " str);
     }) );

    mixin Q_OBJECT;
 }


Thank you for suggestion, but while reducing redundancy it became even uglier! I'll better stay with the current syntax.

To make it look a little better you can do like this: template Slot (ReturnType, alias method, ARGS...) { // code } template Slot (alias method) { mixin Slot!(ReturnType!(method), method, ParameterTypeTuple!(method)); } If the method is overloaded, use the first version, otherwise use the second. Use them like this: class Test : QObject { mixin Slot!(slot_1); void slot_1(string str) { writefln("slot_1 invoked with ~ " str); } mixin Q_OBJECT; }
Dec 14 2009
parent Jacob Carlborg <doob me.com> writes:
On 12/14/09 20:29, Jacob Carlborg wrote:
 On 12/13/09 20:44, Eldar Insafutdinov wrote:
 Nick Sabalausky Wrote:

 "Nick Sabalausky"<a a.a> wrote in message
 news:hg394f$mr1$1 digitalmars.com...
 "Eldar Insafutdinov"<e.insafutdinov gmail.com> wrote in message
 news:hg2p87$2ttj$1 digitalmars.com...
 1) You may know the concept of signals and slots in Qt. Consider the
 following snippet:

 class Test : QObject
 {
 mixin Signal!("signal_1(string)");

 mixin Slot!("slot_1(string str)");
 void slot_1(string str)
 {
 writefln("slot_1 invoked with ~ " str);
 }

 mixin Q_OBJECT;
 }

 In Qt objects, that inherit from QObject are capable of having signals
 and slots and participate in connections. In the current scheme
 mixins of
 Signal and Slot template mix some static information into the
 class. The
 class is then scanned when Q_OBJECT template is mixed in and the
 proper
 meta-information is generated to register signals and slots in the Qt
 type system.
 As you see, this declaration is a bit ugly. In particular defining
 a slot
 requires to duplicate its signature in a mixin. What would really be
 awesome is a mechanism allowing something like:

  Slot
 void slot_1(string str)
 {
 writefln("slot_1 invoked with " ~ str);
 }
 I.e we need annotations. But I am not sure how this will work. One
 of the
 possible solutions will be that  Slot expands into mixin Slot!(symbol,
 AnnotationArg1, ...).


Oops, slight typo:
 Try string mixins, something like this:

 1. Rename Slot to _Slot.

 2. Do this:

// Fixed: template Slot(string decl, string body) { const string Slot = " mixin _Slot!("~decl.stringof~"); void slot_1(string str) { "~body.stringof~" } "; }
 class Test : QObject
 {
 mixin Signal!("signal_1(string)");

 mixin( Slot!("slot_1(string str)", q{
 writefln("slot_1 invoked with ~ " str);
 }) );

 mixin Q_OBJECT;
 }


Thank you for suggestion, but while reducing redundancy it became even uglier! I'll better stay with the current syntax.

To make it look a little better you can do like this: template Slot (ReturnType, alias method, ARGS...) { // code } template Slot (alias method) { mixin Slot!(ReturnType!(method), method, ParameterTypeTuple!(method)); } If the method is overloaded, use the first version, otherwise use the second. Use them like this: class Test : QObject { mixin Slot!(slot_1); void slot_1(string str) { writefln("slot_1 invoked with ~ " str); } mixin Q_OBJECT; }

ReturnType and ParameterTypeTuple are available in std.traits, in Tango they're in tango.core.Traits under slightly different names.
Dec 14 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Eldar Insafutdinov wrote:
 Andrei Alexandrescu Wrote:
 Thanks for cooperation. I don't want to sound like I've given the
 right to ask for features, because I am working on a particular D
 project. But at the same time, indeed, while working on this project
 I found many things that I would like to be improved.

Unfortunately we can't fix all of that stuff mostly because we wouldn't know what path is best to take. But we can and should fix this:
 class Test { void foo(); void foo() {} }

and this:
 6) Various, various compiler bugs. I'm not joking here, I hit dmd
 bugs every single day I work on qtd. It makes it very difficult to
 cut down to sensible testcases, because of the size of the library. I
 filed some bugs, I used all my votes in bugzilla, but neither of
 those got any update within last 2 months. That's a pity. I am sure
 many other people have similar experience.
 
 The main one is probably forward references bug. That's why I have to
 use patched version of dmd (done not by me). Work on it is still in
 progress, and when the author of the patches finishes it and submits
 them to the bugzilla, we would need apply them somehow, as otherwise
 official dmd will not compile QtD.

Absolutely. Thanks for letting us know of the challenges you're facing. I hope many of them would be the start of discussions on how to improve things in D3. Andrei
Dec 13 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Andrei Alexandrescu Wrote:

 Eldar Insafutdinov wrote:
 Andrei Alexandrescu Wrote:
 Thanks for cooperation. I don't want to sound like I've given the
 right to ask for features, because I am working on a particular D
 project. But at the same time, indeed, while working on this project
 I found many things that I would like to be improved.

Unfortunately we can't fix all of that stuff mostly because we wouldn't know what path is best to take. But we can and should fix this:
 class Test { void foo(); void foo() {} }

and this:
 6) Various, various compiler bugs. I'm not joking here, I hit dmd
 bugs every single day I work on qtd. It makes it very difficult to
 cut down to sensible testcases, because of the size of the library. I
 filed some bugs, I used all my votes in bugzilla, but neither of
 those got any update within last 2 months. That's a pity. I am sure
 many other people have similar experience.
 
 The main one is probably forward references bug. That's why I have to
 use patched version of dmd (done not by me). Work on it is still in
 progress, and when the author of the patches finishes it and submits
 them to the bugzilla, we would need apply them somehow, as otherwise
 official dmd will not compile QtD.

Absolutely. Thanks for letting us know of the challenges you're facing. I hope many of them would be the start of discussions on how to improve things in D3. Andrei

So that means that annotations are pended until D3? I thought the work on property will end up with proper annotations. Is it the same for your proposal with mixin(Derived)?
Dec 13 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Eldar Insafutdinov wrote:
 Andrei Alexandrescu Wrote:
 
 Eldar Insafutdinov wrote:
 Andrei Alexandrescu Wrote:
 Thanks for cooperation. I don't want to sound like I've given the
 right to ask for features, because I am working on a particular D
 project. But at the same time, indeed, while working on this project
 I found many things that I would like to be improved.

Unfortunately we can't fix all of that stuff mostly because we wouldn't know what path is best to take. But we can and should fix this:
 class Test { void foo(); void foo() {} }

 6) Various, various compiler bugs. I'm not joking here, I hit dmd
 bugs every single day I work on qtd. It makes it very difficult to
 cut down to sensible testcases, because of the size of the library. I
 filed some bugs, I used all my votes in bugzilla, but neither of
 those got any update within last 2 months. That's a pity. I am sure
 many other people have similar experience.

 The main one is probably forward references bug. That's why I have to
 use patched version of dmd (done not by me). Work on it is still in
 progress, and when the author of the patches finishes it and submits
 them to the bugzilla, we would need apply them somehow, as otherwise
 official dmd will not compile QtD.

Thanks for letting us know of the challenges you're facing. I hope many of them would be the start of discussions on how to improve things in D3. Andrei

So that means that annotations are pended until D3? I thought the work on property will end up with proper annotations. Is it the same for your proposal with mixin(Derived)?

D2 will include properties that are understood by the compiler. We currently don't have a design for user-defined properties. Andrei
Dec 14 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Adam D. Ruppe wrote:
 On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
 D2 will include properties that are understood by the compiler. We 
 currently don't have a design for user-defined properties.

Can I suggest something very simple: make them accessible from __traits, and leave the rest to the library. Accept anything_at_all. myprop int a; assert(__traits(getAnnotations, a) == [ "myprop" ]);

Probably it's easier to (also) offer is(a == myprop). But we couldn't make static foreach part of D2. Andrei
Dec 14 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Adam D. Ruppe wrote:
 On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
 D2 will include properties that are understood by the compiler. We 
 currently don't have a design for user-defined properties.

Can I suggest something very simple: make them accessible from __traits, and leave the rest to the library. Accept anything_at_all. myprop int a; assert(__traits(getAnnotations, a) == [ "myprop" ]);

I just had a little related idea. If you (Eldar) put the property in the naming convention, then you may be able to simplify things by using __traits(allMembers, Type), which works now. For example: all signals start with "signal_" and all slots start with "slot_". Would that work? Andrei
Dec 14 2009
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Adam D. Ruppe wrote:
 On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
 D2 will include properties that are understood by the compiler. We 
 currently don't have a design for user-defined properties.

Can I suggest something very simple: make them accessible from __traits, and leave the rest to the library. Accept anything_at_all. myprop int a; assert(__traits(getAnnotations, a) == [ "myprop" ]);

I just had a little related idea. If you (Eldar) put the property in the naming convention, then you may be able to simplify things by using __traits(allMembers, Type), which works now. For example: all signals start with "signal_" and all slots start with "slot_". Would that work?

It could work for simple things, but it doesn't scale well. If I wanted to use attributes for my D/Objective-C bridge, I'd need them to be parametrized: objc("sizeWithFont:forWidth:lineBreakMode:") CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Currently, this would be: CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); mixin ObjcBindMethod(sizeWithFont, CGSize, "sizeWithFont:forWidth:lineBreakMode:", UIFont, CGFloat, UILineBreakMode); With a naming convention, it'd have to be something like: CGSize objc_sizeWithFont_forWidth_lineBreakMode_(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Shorter to declare, but a pain to use. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 14 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 Adam D. Ruppe wrote:
 On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
 D2 will include properties that are understood by the compiler. We 
 currently don't have a design for user-defined properties.

Can I suggest something very simple: make them accessible from __traits, and leave the rest to the library. Accept anything_at_all. myprop int a; assert(__traits(getAnnotations, a) == [ "myprop" ]);

I just had a little related idea. If you (Eldar) put the property in the naming convention, then you may be able to simplify things by using __traits(allMembers, Type), which works now. For example: all signals start with "signal_" and all slots start with "slot_". Would that work?

It could work for simple things, but it doesn't scale well. If I wanted to use attributes for my D/Objective-C bridge, I'd need them to be parametrized: objc("sizeWithFont:forWidth:lineBreakMode:") CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Currently, this would be: CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); mixin ObjcBindMethod(sizeWithFont, CGSize, "sizeWithFont:forWidth:lineBreakMode:", UIFont, CGFloat, UILineBreakMode); With a naming convention, it'd have to be something like: CGSize objc_sizeWithFont_forWidth_lineBreakMode_(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Shorter to declare, but a pain to use.

Maybe opDispatch could help the use scenario. Andrei
Dec 14 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-12-14 16:04:18 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Michel Fortin wrote:
 On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 Adam D. Ruppe wrote:
 On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
 D2 will include properties that are understood by the compiler. We 
 currently don't have a design for user-defined properties.

Can I suggest something very simple: make them accessible from __traits, and leave the rest to the library. Accept anything_at_all. myprop int a; assert(__traits(getAnnotations, a) == [ "myprop" ]);

I just had a little related idea. If you (Eldar) put the property in the naming convention, then you may be able to simplify things by using __traits(allMembers, Type), which works now. For example: all signals start with "signal_" and all slots start with "slot_". Would that work?

It could work for simple things, but it doesn't scale well. If I wanted to use attributes for my D/Objective-C bridge, I'd need them to be parametrized: objc("sizeWithFont:forWidth:lineBreakMode:") CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Currently, this would be: CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); mixin ObjcBindMethod(sizeWithFont, CGSize, "sizeWithFont:forWidth:lineBreakMode:", UIFont, CGFloat, UILineBreakMode); With a naming convention, it'd have to be something like: CGSize objc_sizeWithFont_forWidth_lineBreakMode_(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Shorter to declare, but a pain to use.

Maybe opDispatch could help the use scenario.

Yeah, perhaps opDispatch could help in the latter case, allowing you to call the function using the first part of the Objective-C name (although that's not sufficient in itself since many methods could have the same first part, the D short name could be "mangled" in the function name too). The bigger problem is that when you use an API, you don't just call functions: you subclass and override functions too. It's pretty interesting to be able to subclass a bridged Objective-C class (such as, say, NSArray, NSWindow, NSApplication) and write your own subclass in D. Having to override functions with names like objc_sizeWithFont_forWidth_lineBreakMode_ is hardly interesting, and opDispatch can't help you with that. Also, what is currently lacking in the D/Objective-C bridge is support for protocols (Objective-C's equivalent to interfaces). It'd be easy to support protocols as interfaces if functions in an interface could be annotated with the corresponding Objective-C function name. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 14 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hg698i$2rpd$1 digitalmars.com...
 Michel Fortin wrote:
 On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:

 Adam D. Ruppe wrote:
 On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
 D2 will include properties that are understood by the compiler. We 
 currently don't have a design for user-defined properties.

Can I suggest something very simple: make them accessible from __traits, and leave the rest to the library. Accept anything_at_all. myprop int a; assert(__traits(getAnnotations, a) == [ "myprop" ]);

I just had a little related idea. If you (Eldar) put the property in the naming convention, then you may be able to simplify things by using __traits(allMembers, Type), which works now. For example: all signals start with "signal_" and all slots start with "slot_". Would that work?

It could work for simple things, but it doesn't scale well. If I wanted to use attributes for my D/Objective-C bridge, I'd need them to be parametrized: objc("sizeWithFont:forWidth:lineBreakMode:") CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Currently, this would be: CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); mixin ObjcBindMethod(sizeWithFont, CGSize, "sizeWithFont:forWidth:lineBreakMode:", UIFont, CGFloat, UILineBreakMode); With a naming convention, it'd have to be something like: CGSize objc_sizeWithFont_forWidth_lineBreakMode_(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Shorter to declare, but a pain to use.

Maybe opDispatch could help the use scenario. Andrei

As opDispatch pushes errors from compile-time to run-time, I don't think we should be encouraging its use for anything that isn't inherently dynamic.
Dec 14 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hg698i$2rpd$1 digitalmars.com...
 Michel Fortin wrote:
 On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:

 Adam D. Ruppe wrote:
 On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
 D2 will include properties that are understood by the compiler. We 
 currently don't have a design for user-defined properties.

__traits, and leave the rest to the library. Accept anything_at_all. myprop int a; assert(__traits(getAnnotations, a) == [ "myprop" ]);

naming convention, then you may be able to simplify things by using __traits(allMembers, Type), which works now. For example: all signals start with "signal_" and all slots start with "slot_". Would that work?

to use attributes for my D/Objective-C bridge, I'd need them to be parametrized: objc("sizeWithFont:forWidth:lineBreakMode:") CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Currently, this would be: CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); mixin ObjcBindMethod(sizeWithFont, CGSize, "sizeWithFont:forWidth:lineBreakMode:", UIFont, CGFloat, UILineBreakMode); With a naming convention, it'd have to be something like: CGSize objc_sizeWithFont_forWidth_lineBreakMode_(UIFont font, CGFloat width, UILineBreakMode lineBreakMode); Shorter to declare, but a pain to use.

Andrei

As opDispatch pushes errors from compile-time to run-time,

We looked to it that it doesn't. Andrei
Dec 14 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-12-14 20:56:12 -0500, "Nick Sabalausky" <a a.a> said:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:hg698i$2rpd$1 digitalmars.com...
 Maybe opDispatch could help the use scenario.
 
 Andrei

As opDispatch pushes errors from compile-time to run-time, I don't think we should be encouraging its use for anything that isn't inherently dynamic.

First, opDispatch is a template, so it's not dynamic dispatch unless your template effectively do its dispatching at runtime. I don't think Andrei was proposing dynamic dispatch here. And since we're talking about dynamic dispatch: for the overridden methods to work when you create a D subclass of an Objective-C class, all methods have to be declared at compile time, even though in Objective-C they're dynamically bound. The goal of the bridge is to expose Objective-C objects as D objects, and thus overriding must work. It'd be pretty useless if it didn't. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 14 2009
parent "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:hg6she$ubg$1 digitalmars.com...
 On 2009-12-14 20:56:12 -0500, "Nick Sabalausky" <a a.a> said:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:hg698i$2rpd$1 digitalmars.com...
 Maybe opDispatch could help the use scenario.

 Andrei

As opDispatch pushes errors from compile-time to run-time, I don't think we should be encouraging its use for anything that isn't inherently dynamic.

First, opDispatch is a template, so it's not dynamic dispatch unless your template effectively do its dispatching at runtime. I don't think Andrei was proposing dynamic dispatch here.

Ahh, I had forgotten that.
Dec 14 2009
prev sibling parent Max Samukha <spambox d-coding.com> writes:
On 14.12.2009 18:41, Andrei Alexandrescu wrote:

 I just had a little related idea. If you (Eldar) put the property in the
 naming convention, then you may be able to simplify things by using
 __traits(allMembers, Type), which works now.

 For example: all signals start with "signal_" and all slots start with
 "slot_".

 Would that work?


 Andrei

I think we'll use that approach as a stop-gap. Thanks!
Dec 17 2009
prev sibling next sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Eldar Insafutdinov Wrote:

 The main one is probably forward references bug. That's why I have to use
patched version of dmd (done not by me). Work on it is still in progress, and
when the author of the patches finishes it and submits them to the bugzilla, we
would need apply them somehow, as otherwise official dmd will not compile QtD.

Rainer Schuetze has completed his patches, the latest versions are attached to bug reports 102, 2511 and 3600. We use them to compile QtD currently. If applied it will greatly facilitate the development and usage of QtD. One other patch of the compiler involves a semantic change (__traits), of which we are going to post tomorrow.
Dec 29 2009
prev sibling next sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Eldar Insafutdinov Wrote:

 The main one is probably forward references bug. That's why I have to use
patched version of dmd (done not by me). Work on it is still in progress, and
when the author of the patches finishes it and submits them to the bugzilla, we
would need apply them somehow, as otherwise official dmd will not compile QtD.

Rainer Schuetze has completed his patches, the latest versions are attached to bug reports 102, 2511 and 3600. We use them to compile QtD currently. If applied it will greatly facilitate the development and usage of QtD. One other patch of the compiler involves a semantic change (__traits), of which we are going to post tomorrow.
Dec 29 2009
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Eldar Insafutdinov Wrote:

 The main one is probably forward references bug. That's why I have to use
patched version of dmd (done not by me). Work on it is still in progress, and
when the author of the patches finishes it and submits them to the bugzilla, we
would need apply them somehow, as otherwise official dmd will not compile QtD.

Rainer Schuetze has completed his patches, the latest versions are attached to bug reports 102, 2511 and 3600. We use them to compile QtD currently. If applied it will greatly facilitate the development and usage of QtD. One other patch of the compiler involves a semantic change (__traits), of which we are going to post tomorrow.
Dec 29 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Eldar Insafutdinov Wrote:

 Eldar Insafutdinov Wrote:
 
 The main one is probably forward references bug. That's why I have to use
patched version of dmd (done not by me). Work on it is still in progress, and
when the author of the patches finishes it and submits them to the bugzilla, we
would need apply them somehow, as otherwise official dmd will not compile QtD.

Rainer Schuetze has completed his patches, the latest versions are attached to bug reports 102, 2511 and 3600. We use them to compile QtD currently. If applied it will greatly facilitate the development and usage of QtD. One other patch of the compiler involves a semantic change (__traits), of which we are going to post tomorrow.

Sorry for the flood, the Firefox seemed to play with me.
Dec 29 2009
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
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.
Dec 12 2009
parent "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:hg0keb$2iq2$1 digitalmars.com...
 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.

Speaking purely (and proudly) as a non-lawyer: For being only three paragraphs long, the Boost license is amazingly obtuse. The first two paragraphs are made up of one full-paragraph-sized sentence each, and in a style that's the written-word equivilent of constipation (kinda like how my dad explains things: keeps talking and yet somehow never gets to the ^&**& point.) Then the third paragraph, of course, is every laywer's big stiffy: the ALL CAPS paragraph.
Dec 12 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
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.

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?
Dec 12 2009
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Dec 12, 2009 at 07:53:20PM +0100, BLS wrote:
 If you don't care : make it public domain.

I argued this with my boss once. He said public domain is unacceptable to him because: a) It doesn't disclaim liability; if your public domain thing screws up, you can, in theory anyway, be sued into oblivion over it. and b) Some countries don't recognize public domain. The zlib license addresses both these, while keeping the rest of the "do whatever" attitude, so that's what he insists on for this kind of thing. -- Adam D. Ruppe http://arsdnet.net
Dec 12 2009
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Dec 12, 2009 at 06:40:49PM +0000, retard wrote:
 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 look at it the opposite way: the BSD license is insulting to its users. "Your wishes aren't worth a crap, you MUST stroke my ego." -- Adam D. Ruppe http://arsdnet.net
Dec 12 2009
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Dec 12, 2009 at 03:14:18PM -0500, Nick Sabalausky wrote:
 Adam also said there's a liability issue, but (IANAL) that would surprise me 
 because AIUI, public domain is all about severing *all* ties between an 
 author and their work. But then again, that's probably just one of those 
 things that differs by country.

Neither myself nor my boss are lawyers either, so this might not be completely accurate, but the worry he explained was if you provide something, there is an automatic warranty on it: you are implicitly saying that it is fit for the purpose you are providing it for and taking responsibility for safety issues associated with it. The big ALL CAPS paragraph in most licenses specifically disclaims this, whereas offering something that is public domain doesn't, so the assumption is that the implicit warranty from distributing it is still there. -- Adam D. Ruppe http://arsdnet.net
Dec 12 2009
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 12 Dec 2009 15:14:18 -0500, Nick Sabalausky wrote:

 "BLS" <windevguy hotmail.de> wrote in message
 news:hg0or1$2rtu$1 digitalmars.com...
 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.

I'm really tired of public domain constantly being tossed around as if it were actually a reasonable option: 1. If you put someting in PD, you're no longer legally allowed to claim that you actually wrote it (leave it to a government to try to redefine reality like that...). In other words, you're not allowed to state an actual fact about it. 2. Different countries define public domain differently, some countries don't define it, and others don't even have a concept of public domain at all. Adam also said there's a liability issue, but (IANAL) that would surprise me because AIUI, public domain is all about severing *all* ties between an author and their work. But then again, that's probably just one of those things that differs by country. The thing about zlib (or something like beerware) is that it's basically a version of public domain that *isn't* total crap.
 if you want to share : make it GPL 3

That's just BS. It's more like this: If you want to share *only* with people who, #1 also want to share everything they do with it, *and* #2 don't mind dealing with a fifty-foot wall of legalese gibberish that's completely impenetrable without shelling out bucks for a lawyer that'll probably cost them more than if you had just charged a basic fee in the first place: Make it GPL.

FWIW, I think the longest license conditions usually come with proprietary applications. Sometimes I'm not even sure if I'm allowed to use the software I just payed for. IIRC if you use e.g. microsoft messenger, you have to defend them in court if they insist. If you trust the FSF and GPL, using it isn't that big a deal. Some IDEs even have plugins that add the license text to all source files. Tagging a 10000 file project takes less than a second. In addition to that, just provide a COPYING file with the distribution package.
 
 If you *just simply want to share*: Make it zlib, or maybe beerware or
 something like that.

It's silly so say that those are the only alternatives. If I plan to use GPL or BSD, it's my personal choice and there's nothing you can do. The desire to share with everyone is like sharing your genitals with every (possibly HIV carrying person) person on earth. Sometimes it's a good idea, sometimes it isn't.
Dec 12 2009
parent "Chris" <invalid invalid.invalid> writes:
"retard"
 IIRC if you use e.g. microsoft messenger, you have to defend them in court
 if they insist.

Please, can you explain this, and where exactly this clause appear? Thank you.
Dec 13 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 13 Dec 2009 17:50:03 +0100, Chris wrote:

 "retard"
 IIRC if you use e.g. microsoft messenger, you have to defend them in
 court if they insist.

Please, can you explain this, and where exactly this clause appear? Thank you.

IIRC in the EULA of some previous version of the messenger application. I don't remember the exact form, though. I just checked the EULA from the version 7, but it didn't contain that text anymore. Unfortunately I don't have time to verify my claims, but I'm sure the EULAs from win95/win98 era messagers can either prove me right or wrong.
Dec 13 2009
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
 D2 will include properties that are understood by the compiler. We 
 currently don't have a design for user-defined properties.

Can I suggest something very simple: make them accessible from __traits, and leave the rest to the library. Accept anything_at_all. myprop int a; assert(__traits(getAnnotations, a) == [ "myprop" ]); That's all the compiler needs to do. Then, in the library, we combine it with some magic to do the actual work. Something like this: ========= class A { mixin(SIGNALS_AND_SLOTS!(A)); slot void fun() { } } string SIGNALS_AND_SLOTS(T)() { string data; static foreach(member, __traits(getMembers, T)) { static if(inArray(__traits(getAnnotations, member), "slot")) { data ~= "whatever implementation"; } } return data; } ========== It is a little clunky, but it at least makes it accessible to libraries, where they can figure out some way to work with it. It seems like it should be fairly simple in the compiler - it is just keeping a list of strings.
 
 Andrei

-- Adam D. Ruppe http://arsdnet.net
Dec 14 2009
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Mon, Dec 14, 2009 at 07:42:51AM -0800, Andrei Alexandrescu wrote:
 Probably it's easier to (also) offer is(a ==  myprop).

Yeah, that works too. As long as we have some kind of building block.
 But we couldn't make static foreach part of D2.

Oh well, no big deal; we can make do without it. -- Adam D. Ruppe http://arsdnet.net
Dec 14 2009
prev sibling next sibling parent torhu <no spam.invalid> writes:
On 12.12.2009 6: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.

DWT works on at least Windows and linux, has a very permissive license, great online docs (including a good free book), and is easy to use. It's also got great perfomance, at least on Windows. The new DWT2 branch (http://hg.dsource.org/projects/dwt2) supports both Tango with D1, and Phobos with D2. The Tango implementation works fine, but the phobos one looks to be incomplete. In other words, some work is required if you are going to use D 2. The low-level Java classes (I/O, threading, containers, etc), are implemented separately for Tango and Phobos, then the rest of the library uses those instead of Tango or Phobos directly. http://dsource.org/projects/dwt/
Dec 13 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
BLS, el 12 de diciembre a las 19:53 me escribiste:
 if you want to make money : make it close source.

You got it *so* wrong. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- ... los cuales son susceptibles a una creciente variedad de ataques previsibles, tales como desbordamiento del tampĆ³n, falsificaciĆ³n de parĆ”metros, ... -- Stealth - ISS LLC - Seguridad de IT
Dec 13 2009