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


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


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


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


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


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

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


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


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


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

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

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

- If every program insists on having it's own different look, then my system 

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 


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


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


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


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








ver

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








a

 native Win32 look and feel got in the way of me using a program
 effectively.


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


 Right, the implication here was that I mostly use Windows and I've never
 really
 cared if an application I use has a GTK-ish or Swing-ish or whatever loo=




k

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




t

 works
 and is usable.


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


er

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


t

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


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


Because the Boost license doesn't require attribution for works only distributed
in binary form.
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.


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


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


The zlib license, then.
Dec 12 2009
prev sibling next sibling parent reply 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.


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


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


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


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


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


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


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



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


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


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


 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


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



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


[snip]

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.


 [snip]
 
 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.


 [snip]

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


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



  parent reply "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



 next 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" ]);


Probably it's easier to (also) offer is(a ==  myprop).

But we couldn't make static foreach part of D2.

Andrei



 Dec 14 2009



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


 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,


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


Some bits I have forgotten to write about in my previous post.

- We really need an access for an original object in copy constructor in
structures, as this structures emulate C++ classes directly and we need to call
C++ copy constructors from this(this). But C++ ctors require original object.

Currently this could be done like:

struct QImage
{
ubyte[SIZE_OF_QIMAGE] data;

this(this)
{
    ubyte[SIZE_OF_QIMAGE] dummy;
    memcpy(dummy.ptr, &this, SIZE_OF_QIMAGE);
    call_QImage_copy_ctor(dummy.ptr, &this);
}

extern (C) call_QImage_copy_ctor(void* src, void* dst);

// C++

extern "C" call_QImage_copy_ctor(QImage* src, QImage* dst)
{
   dst->QImage(*src);
}

We emulated original object by doing creating a dummy buffer, but that requires
extra memcpy. Having an identifier like __source which will be a reference to
original structure will be a good thing. You don't have to use it all the time,
but in rare cases when you really need it - it is here.

- Another good use case for annotations is to allow grouped declarations:

 Signal
{
    void fooed();
    void booed();
}



 Dec 13 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 next sibling parent reply bobef <adsad askdfkasjflaflajf.asdasd>  writes:


Andrei Alexandrescu Wrote:


 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


Speaking of pushing things forward, please guys, push whatever is needed to
push Tango to D2. I was (once again) inspecting the possibility of switching to
D2, and phobos goes nowhere near (near is not the right word, it goes nowhere
far far far far near) Tango. Comparison is simply impossible (no offense,
really). This, at lest for myself, means no D2. So please, please, please ask
the same question to the Tango guys: "If there is anything in the language that
prevents you from getting things done, please let us know." I recently asked in
the Tango forum why there is still no D2 Tango and the answer was because const
is inflexible. I don't know what that means as I never use consts, but please
resolve it, because IMO Tango is probably (at the moment), along with the GUI
libraries, the most import D project. It is hard to tell if GUI is more
important or Tango, but I would vote for Tango.



 Dec 14 2009



  parent  "Nick Sabalausky" <a a.a>  writes:


"bobef" <adsad askdfkasjflaflajf.asdasd> wrote in message 
news:hg5qr6$1t97$1 digitalmars.com...

 Andrei Alexandrescu Wrote:


 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


 Speaking of pushing things forward, please guys, push whatever is needed 
 to push Tango to D2. I was (once again) inspecting the possibility of 
 switching to D2, and phobos goes nowhere near (near is not the right word, 
 it goes nowhere far far far far near) Tango. Comparison is simply 
 impossible (no offense, really). This, at lest for myself, means no D2. So 
 please, please, please ask the same question to the Tango guys: "If there 
 is anything in the language that prevents you from getting things done, 
 please let us know." I recently asked in the Tango forum why there is 
 still no D2 Tango and the answer was because const is inflexible. I don't 
 know what that means as I never use consts, but please resolve it, because 
 IMO Tango is probably (at the moment), along with the GUI libraries, the 
 most import D project. It is hard to tell if GUI is more important or 
 Tango, but I would vote for Tango.


Yea, Tango is probably the main reason all my libs and code are D1 atm. But, 
AIUI, one of D2's biggest showstoppers for Tango is just simply being a 
moving target (which is also the secondary reason my stuff is still D1). So 
that's largely just a "finish D2" thing, which is already being pushed as 
much as it can be :) 



 Dec 14 2009



prev sibling  parent  Kagamin <spam here.lot>  writes:


Nick Sabalausky Wrote:


 Something like this would be much better: Have a 
 system where it's possible to install add-ons to the system dialog boxes.


There's no such native system, but gtk does the job.



 Dec 15 2009