www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Qt bindings for D

reply "Abdulhaq" <alynch4047 gmail.com> writes:
Hi guys

a few months ago I tried to find working bindings for Qt and the 
best I could see was qtd. I tried compiling it but it didn't go 
too well on my Linux 64bit machine, and saw in the forums that 
the original developers had ceased maintaining it. Because I have 
been using Qt for around 10 years or so now (mainly from python 
but a little C++ too) I had a go at getting it to work again.

It took a few weekends but I got the main examples going (Core, 
GUI, XML etc) with Qt 4.8 and 2.062. I felt that I was having to 
do some rewinding of where the original developers were going (it 
seemed that they were trying to take QRect et al down the struct 
route, but my to my newbie eyes it seemed doomed because it was 
making assumptions about the way the C++ and D compilers were 
laying out the struct data that didn't work on my machine - but I 
could be wrong about that). Anyway I treated it as an educational 
exercise and make QRect et al. regular classes, and got it 
generally working again.

Then real life took over again and I had to shelve the project, 
but now I have a little spare time again. I suspect there are 
other developers such as myself out there who are keen to try D 
but would like to use it with Qt, so I thought I would let you 
know what I had done in case others were interested. I'm kind of 
hoping that someone will say that the job is already done, but I 
suspect that is not the case.

The original developers did a really great job of the wrapping 
and left the build system in a really good state too. However, 
there seems to be very little testing other than the standard qt 
examples themselves, so I can't be sure exactly where the 
wrapping stands. Although the original developers felt that it 
had some way to go before being really useful, it seems to me 
that they had achieved more than that and that some would want to 
use it as it stood.

Unfortunately the wrapping is based on QtJambi, which is now 
dead, but anyway it's easy with hindsight isn't it.

Is anyone else interested and can anyone help me with polishing 
it? It needs testing, trying out on Windows, and some 
improvements to the build system. I have very little time ATM but 
it would be good to capture where I've got to so that others 
could pick it up or just experiment with D and Qt.

regards
Abdulhaq
Oct 13 2013
next sibling parent reply "Elvis Zhou" <elvis.x.zhou gmail.com> writes:
On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Hi guys

 a few months ago I tried to find working bindings for Qt and 
 the best I could see was qtd. I tried compiling it but it 
 didn't go too well on my Linux 64bit machine, and saw in the 
 forums that the original developers had ceased maintaining it. 
 Because I have been using Qt for around 10 years or so now 
 (mainly from python but a little C++ too) I had a go at getting 
 it to work again.

 It took a few weekends but I got the main examples going (Core, 
 GUI, XML etc) with Qt 4.8 and 2.062. I felt that I was having 
 to do some rewinding of where the original developers were 
 going (it seemed that they were trying to take QRect et al down 
 the struct route, but my to my newbie eyes it seemed doomed 
 because it was making assumptions about the way the C++ and D 
 compilers were laying out the struct data that didn't work on 
 my machine - but I could be wrong about that). Anyway I treated 
 it as an educational exercise and make QRect et al. regular 
 classes, and got it generally working again.

 Then real life took over again and I had to shelve the project, 
 but now I have a little spare time again. I suspect there are 
 other developers such as myself out there who are keen to try D 
 but would like to use it with Qt, so I thought I would let you 
 know what I had done in case others were interested. I'm kind 
 of hoping that someone will say that the job is already done, 
 but I suspect that is not the case.

 The original developers did a really great job of the wrapping 
 and left the build system in a really good state too. However, 
 there seems to be very little testing other than the standard 
 qt examples themselves, so I can't be sure exactly where the 
 wrapping stands. Although the original developers felt that it 
 had some way to go before being really useful, it seems to me 
 that they had achieved more than that and that some would want 
 to use it as it stood.

 Unfortunately the wrapping is based on QtJambi, which is now 
 dead, but anyway it's easy with hindsight isn't it.

 Is anyone else interested and can anyone help me with polishing 
 it? It needs testing, trying out on Windows, and some 
 improvements to the build system. I have very little time ATM 
 but it would be good to capture where I've got to so that 
 others could pick it up or just experiment with D and Qt.

 regards
 Abdulhaq


Is it Qt5 compatible?
Oct 13 2013
parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
On Sunday, 13 October 2013 at 13:45:13 UTC, Elvis Zhou wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Hi guys

 a few months ago I tried to find working bindings for Qt and 
 the best I could see was qtd. I tried compiling it but it 
 didn't go too well on my Linux 64bit machine, and saw in the 
 forums that the original developers had ceased maintaining it. 
 Because I have been using Qt for around 10 years or so now 
 (mainly from python but a little C++ too) I had a go at 
 getting it to work again.

 It took a few weekends but I got the main examples going 
 (Core, GUI, XML etc) with Qt 4.8 and 2.062.


 Is it Qt5 compatible?


I'd hope so, barring a few tweaks, but due to time constraints I 
haven't made any attempt at that yet. It certainly hasn't got any 
of the QML stuff though.

The wrapper works by declaring classes and methods to be wrapped 
in XML files, so any new classes introduced in 4.9+ wil not be 
present.
Oct 13 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 13.10.2013 16:22, schrieb Abdulhaq:

 On Sunday, 13 October 2013 at 13:45:13 UTC, Elvis Zhou wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Hi guys

 a few months ago I tried to find working bindings for Qt and the best
 I could see was qtd. I tried compiling it but it didn't go too well
 on my Linux 64bit machine, and saw in the forums that the original
 developers had ceased maintaining it. Because I have been using Qt
 for around 10 years or so now (mainly from python but a little C++
 too) I had a go at getting it to work again.

 It took a few weekends but I got the main examples going (Core, GUI,
 XML etc) with Qt 4.8 and 2.062.


 Is it Qt5 compatible?


 I'd hope so, barring a few tweaks, but due to time constraints I haven't
 made any attempt at that yet. It certainly hasn't got any of the QML
 stuff though.

 The wrapper works by declaring classes and methods to be wrapped in XML
 files, so any new classes introduced in 4.9+ wil not be present.



Qt had quite a lot of breaking changes in 5.x versions, so it won't be 
that easy.

--
Paulo
Oct 13 2013
parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Sunday, 13 October 2013 at 15:44:18 UTC, Paulo Pinto wrote:

 Am 13.10.2013 16:22, schrieb Abdulhaq:

 On Sunday, 13 October 2013 at 13:45:13 UTC, Elvis Zhou wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Hi guys

 a few months ago I tried to find working bindings for Qt and 
 the best
 I could see was qtd. I tried compiling it but it didn't go 
 too well
 on my Linux 64bit machine, and saw in the forums that the 
 original
 developers had ceased maintaining it. Because I have been 
 using Qt
 for around 10 years or so now (mainly from python but a 
 little C++
 too) I had a go at getting it to work again.

 It took a few weekends but I got the main examples going 
 (Core, GUI,
 XML etc) with Qt 4.8 and 2.062.


 Is it Qt5 compatible?


 I'd hope so, barring a few tweaks, but due to time constraints 
 I haven't
 made any attempt at that yet. It certainly hasn't got any of 
 the QML
 stuff though.

 The wrapper works by declaring classes and methods to be 
 wrapped in XML
 files, so any new classes introduced in 4.9+ wil not be 
 present.



 Qt had quite a lot of breaking changes in 5.x versions, so it 
 won't be that easy.

 --
 Paulo


Yep I just checked and have to agree with you
Oct 13 2013
prev sibling parent reply "Elvis Zhou" <elvis.x.zhou gmail.com> writes:
On Sunday, 13 October 2013 at 14:22:05 UTC, Abdulhaq wrote:

 On Sunday, 13 October 2013 at 13:45:13 UTC, Elvis Zhou wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Hi guys

 a few months ago I tried to find working bindings for Qt and 
 the best I could see was qtd. I tried compiling it but it 
 didn't go too well on my Linux 64bit machine, and saw in the 
 forums that the original developers had ceased maintaining 
 it. Because I have been using Qt for around 10 years or so 
 now (mainly from python but a little C++ too) I had a go at 
 getting it to work again.

 It took a few weekends but I got the main examples going 
 (Core, GUI, XML etc) with Qt 4.8 and 2.062.


 Is it Qt5 compatible?


 I'd hope so, barring a few tweaks, but due to time constraints 
 I haven't made any attempt at that yet. It certainly hasn't got 
 any of the QML stuff though.

 The wrapper works by declaring classes and methods to be 
 wrapped in XML files, so any new classes introduced in 4.9+ wil 
 not be present.


It will gain more attention if targeting Qt5 IMHO.
Oct 13 2013
parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Sunday, 13 October 2013 at 16:05:24 UTC, Elvis Zhou wrote:

 On Sunday, 13 October 2013 at 14:22:05 UTC, Abdulhaq wrote:

 On Sunday, 13 October 2013 at 13:45:13 UTC, Elvis Zhou wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Hi guys

 a few months ago I tried to find working bindings for Qt and 
 the best I could see was qtd. I tried compiling it but it 
 didn't go too well on my Linux 64bit machine, and saw in the 
 forums that the original developers had ceased maintaining 
 it. Because I have been using Qt for around 10 years or so 
 now (mainly from python but a little C++ too) I had a go at 
 getting it to work again.

 It took a few weekends but I got the main examples going 
 (Core, GUI, XML etc) with Qt 4.8 and 2.062.


 Is it Qt5 compatible?


 I'd hope so, barring a few tweaks, but due to time constraints 
 I haven't made any attempt at that yet. It certainly hasn't 
 got any of the QML stuff though.

 The wrapper works by declaring classes and methods to be 
 wrapped in XML files, so any new classes introduced in 4.9+ 
 wil not be present.


 It will gain more attention if targeting Qt5 IMHO.



Agreed but that is a much bigger task than getting qtd/4.8 going 
well. As a long time Qt developer I'm very happy with 4.8 as a 
very classy cross-platform GUI, and having it as a solid option 
would make D a very interesting language for me - I don't need 
the convenience of the declarative option, or the mobile API. I'd 
really like to get VTK visualisation toolkit going too, but I 
guess than can wait for the Xmas hols :-)
Oct 13 2013
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 […]
 Unfortunately the wrapping is based on QtJambi, which is now 
 dead, but anyway it's easy with hindsight isn't it.

 Is anyone else interested and can anyone help me with polishing 
 it? […]


I'm very interested in having solid Qt bindings available, and I 
worked on QtD a while back.

One thing I've been wondering about is whether keeping the 
QtJambi-based generator makes sense or if it would be easier 
start anew from some of the more active binding projects…

David
Oct 13 2013
next sibling parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Sunday, 13 October 2013 at 16:20:33 UTC, David Nadlinger wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 […]
 Unfortunately the wrapping is based on QtJambi, which is now 
 dead, but anyway it's easy with hindsight isn't it.

 Is anyone else interested and can anyone help me with 
 polishing it? […]


 I'm very interested in having solid Qt bindings available, and 
 I worked on QtD a while back.

 One thing I've been wondering about is whether keeping the 
 QtJambi-based generator makes sense or if it would be easier 
 start anew from some of the more active binding projects…

 David


I think QtJambi solved a lot of problems that you get when 
binding Java to C++, but I'm not so sure about how it helps with 
D. The rich XML specification files must have very helpful, and 
the handling of how Qt automatically deletes child objects when 
reqd must have been useful.

Having used Qt extensively with python I know that performance is 
not a huge issue so clarity of the binding is more important. As 
a D newbie there's some complicated coding going on in qtd that 
is hard to grok and few tests.

However I'm pretty sure that starting over would take a lot 
longer than finishing what's there now, tempting though the idea 
is:-)

My current feeling is that what is needed is plenty of tests 
around memory handling, array handling, signals and slots, and 
the more unusual method calls. Get rid of any remaining code that 
does not easily run in a croos-platform manner.
Oct 13 2013
prev sibling next sibling parent reply "Christian Manning" <cmanning999 gmail.com> writes:
On Sunday, 13 October 2013 at 16:20:33 UTC, David Nadlinger wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 […]
 Unfortunately the wrapping is based on QtJambi, which is now 
 dead, but anyway it's easy with hindsight isn't it.

 Is anyone else interested and can anyone help me with 
 polishing it? […]


 I'm very interested in having solid Qt bindings available, and 
 I worked on QtD a while back.

 One thing I've been wondering about is whether keeping the 
 QtJambi-based generator makes sense or if it would be easier 
 start anew from some of the more active binding projects…

 David


Perhaps KDE's SMOKE? 
http://techbase.kde.org/Development/Languages/Smoke
Oct 13 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/13/13, Christian Manning <cmanning999 gmail.com> wrote:

 Perhaps KDE's SMOKE?
 http://techbase.kde.org/Development/Languages/Smoke


Someone is already working on this:
https://github.com/w0rp/dqt
Oct 13 2013
next sibling parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Sunday, 13 October 2013 at 18:12:00 UTC, Andrej Mitrovic wrote:

 On 10/13/13, Christian Manning <cmanning999 gmail.com> wrote:

 Perhaps KDE's SMOKE?
 http://techbase.kde.org/Development/Languages/Smoke


 Someone is already working on this:
 https://github.com/w0rp/dqt


If I had the time to start from scratch then that would be a very 
interesting option.
Oct 13 2013
prev sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Sunday, 13 October 2013 at 18:12:00 UTC, Andrej Mitrovic wrote:

 On 10/13/13, Christian Manning <cmanning999 gmail.com> wrote:

 Perhaps KDE's SMOKE?
 http://techbase.kde.org/Development/Languages/Smoke


 Someone is already working on this:
 https://github.com/w0rp/dqt


I just saw this thread, and I guess the first thing I felt was 
guilt. I actually got to a pretty interesting stage in this 
project I think, and I do intend to continue working on it. It's 
just that as I was getting to a really cool part where I could 
start to build the bindings proper, life took over and I've been 
far too busy with other things these past few weeks. So, 
unfortunately I haven't had the time to work on it recently. I 
will come back to the project, but it might not be until early 
November when I'll have to the time to pick it up again.

If anyone else wants to take a look at what I did or ask me any 
questions about it, feel free. I pretty much cobbled together 
some code for using Qt through SMOKE in D. SMOKE is pretty much a 
C++ library for creating language bindings for other C++ 
libraries. After spening some time talking to people in the 
#kde-bindings channel and tinkering, I basically matched the 
SMOKE data alignment and wrote a few functions for pulling out 
and calling function pointers in D. (With just a little bit of 
help from a tiny C++ library I wrote, as I couldn't be sure about 
calling C++ function pointers through D working well, among a 
couple of other things.)

I was planning on spending a lot of time thinking about the best 
way I could imagine of putting all of this stuff together, 
providing bindings for the interesting parts of Qt 4.8 (for now), 
and then making a post here announcing the whole thing more 
officially. I suppose this post has kind of pre-empted that.
Oct 13 2013
parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
On Sunday, 13 October 2013 at 20:33:41 UTC, w0rp wrote:

 On Sunday, 13 October 2013 at 18:12:00 UTC, Andrej Mitrovic 
 wrote:

 On 10/13/13, Christian Manning <cmanning999 gmail.com> wrote:

 Perhaps KDE's SMOKE?
 http://techbase.kde.org/Development/Languages/Smoke


 Someone is already working on this:
 https://github.com/w0rp/dqt


 If anyone else wants to take a look at what I did or ask me any 
 questions about it, feel free. I pretty much cobbled together 
 some code for using Qt through SMOKE in D. SMOKE is pretty much 
 a C++ library for creating language bindings for other C++ 
 libraries. After spening some time talking to people in the 
 #kde-bindings channel and tinkering, I basically matched the 
 SMOKE data alignment and wrote a few functions for pulling out 
 and calling function pointers in D. (With just a little bit of 
 help from a tiny C++ library I wrote, as I couldn't be sure 
 about calling C++ function pointers through D working well, 
 among a couple of other things.)

 I was planning on spending a lot of time thinking about the 
 best way I could imagine of putting all of this stuff together, 
 providing bindings for the interesting parts of Qt 4.8 (for 
 now), and then making a post here announcing the whole thing 
 more officially. I suppose this post has kind of pre-empted 
 that.


Because Qt is so large, the binding needs to be autogenerated 
from a representation of the API. Have you done anything / 
thought about how you would do that? It looks like SMOKE already 
has a representation of the API somewhere.

Also, does SMOKE do anything for you in terms of signals and 
slots, and QVariants?
Oct 14 2013
next sibling parent reply Robert Schadek <realburner gmx.de> writes:
On 10/14/2013 12:28 PM, Abdulhaq wrote:

 Also, does SMOKE do anything for you in terms of signals and slots,
 and QVariants?


Signal and Slots are sort of replaced by "normal" methods and a
different connect function in Qt5, which is awesome, because you will
get compile time errors instead of runtime errors.
Oct 14 2013
parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Monday, 14 October 2013 at 10:38:21 UTC, Robert Schadek wrote:

 On 10/14/2013 12:28 PM, Abdulhaq wrote:

 Also, does SMOKE do anything for you in terms of signals and 
 slots,
 and QVariants?


 Signal and Slots are sort of replaced by "normal" methods and a
 different connect function in Qt5, which is awesome, because 
 you will
 get compile time errors instead of runtime errors.


OK sounds good! I just read an early Qt5 blog post that indicates 
that they're still using the MOC for signals - you might need to 
pay some attention to that, maybe not?
Oct 14 2013
prev sibling parent "w0rp" <devw0rp gmail.com> writes:
On Monday, 14 October 2013 at 10:28:32 UTC, Abdulhaq wrote:

 Because Qt is so large, the binding needs to be autogenerated 
 from a representation of the API. Have you done anything / 
 thought about how you would do that? It looks like SMOKE 
 already has a representation of the API somewhere.

 Also, does SMOKE do anything for you in terms of signals and 
 slots, and QVariants?


What SMOKE gives you is a bunch of data which lets you find 
function pointers given a few strings. So with the API I layered 
on top of the SMOKE data, I have something like this:

auto cls = qtSmokeLoader.demandClass("QLabel");
MethodFunctor qLabelCTOR = cls.demandMethod("QLabel", "const 
QString&",
         "QWidget*", "QFlags<Qt::WindowType>");

Which gives me a functor I can call and pass in a few values, 
like void* for Qt classes and a few other primitives. I expose 
that with a more strongly-typed API which uses familiar D types, 
like these:

this(wstring text, QWidget parent = null, WindowType f = 
WindowType.Widget) {}
this(string text, QWidget parent = null, WindowType f = 
WindowType.Widget) {}

QWidget there being the wrapper class seen in D code. All of this 
can be seen for example here: 
https://github.com/w0rp/dqt/blob/master/src/dqt/qlabel.d

It was my intention to write a D program which generates the D 
source files for all of Qt, using something like the above. I was 
once cocerned about the cost in the startup time for all of this, 
but it turned out to be very fast, with potential for a few 
improvements too. So really my biggest concern was just trying to 
think of the best D API to present, which I think is the hardest 
part.
Oct 14 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/13/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 Someone is already working on this:
 https://github.com/w0rp/dqt


Oh and there seems to be someone else working on QtD as well:
https://bitbucket.org/michaelc37/qtd-experimental
Oct 20 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 20 October 2013 at 22:16:50 UTC, Andrej Mitrovic wrote:

 Oh and there seems to be someone else working on QtD as well:
 https://bitbucket.org/michaelc37/qtd-experimental


Michael has been posting in this thread already. ;)

David
Oct 20 2013
prev sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Sunday, 13 October 2013 at 16:20:33 UTC, David Nadlinger wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 […]
 Unfortunately the wrapping is based on QtJambi, which is now 
 dead, but anyway it's easy with hindsight isn't it.

 Is anyone else interested and can anyone help me with 
 polishing it? […]


 I'm very interested in having solid Qt bindings available, and 
 I worked on QtD a while back.

 One thing I've been wondering about is whether keeping the 
 QtJambi-based generator makes sense or if it would be easier 
 start anew from some of the more active binding projects…

 David


As far as I can tell, Qt Jambi does have an successor. Wouldn't 
be surprised if you could reuse almost all of the XML files.

http://qt-project.org/wiki/PySide_Binding_Generator
Oct 14 2013
parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Monday, 14 October 2013 at 10:40:53 UTC, Tobias Pankrath wrote:

 On Sunday, 13 October 2013 at 16:20:33 UTC, David Nadlinger 
 wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 […]
 Unfortunately the wrapping is based on QtJambi, which is now 
 dead, but anyway it's easy with hindsight isn't it.

 Is anyone else interested and can anyone help me with 
 polishing it? […]


 I'm very interested in having solid Qt bindings available, and 
 I worked on QtD a while back.

 One thing I've been wondering about is whether keeping the 
 QtJambi-based generator makes sense or if it would be easier 
 start anew from some of the more active binding projects…

 David


 As far as I can tell, Qt Jambi does have an successor. Wouldn't 
 be surprised if you could reuse almost all of the XML files.

 http://qt-project.org/wiki/PySide_Binding_Generator


that's interesting, thanks. A migration to Qt5 would still (at 
least) need a rejig of the build system and some changes to the 
MOC (signals/slots handling) but having the XML available makes 
it something to consider.
Oct 14 2013
prev sibling next sibling parent reply "michaelc37" <michaelc37 msn.com> writes:
On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Hi guys

 a few months ago I tried to find working bindings for Qt and 
 the best I could see was qtd. I tried compiling it but it 
 didn't go too well on my Linux 64bit machine, and saw in the 
 forums that the original developers had ceased maintaining it. 
 Because I have been using Qt for around 10 years or so now 
 (mainly from python but a little C++ too) I had a go at getting 
 it to work again.

 It took a few weekends but I got the main examples going (Core, 
 GUI, XML etc) with Qt 4.8 and 2.062. I felt that I was having 
 to do some rewinding of where the original developers were 
 going (it seemed that they were trying to take QRect et al down 
 the struct route, but my to my newbie eyes it seemed doomed 
 because it was making assumptions about the way the C++ and D 
 compilers were laying out the struct data that didn't work on 
 my machine - but I could be wrong about that). Anyway I treated 
 it as an educational exercise and make QRect et al. regular 
 classes, and got it generally working again.

 Then real life took over again and I had to shelve the project, 
 but now I have a little spare time again. I suspect there are 
 other developers such as myself out there who are keen to try D 
 but would like to use it with Qt, so I thought I would let you 
 know what I had done in case others were interested. I'm kind 
 of hoping that someone will say that the job is already done, 
 but I suspect that is not the case.

 The original developers did a really great job of the wrapping 
 and left the build system in a really good state too. However, 
 there seems to be very little testing other than the standard 
 qt examples themselves, so I can't be sure exactly where the 
 wrapping stands. Although the original developers felt that it 
 had some way to go before being really useful, it seems to me 
 that they had achieved more than that and that some would want 
 to use it as it stood.

 Unfortunately the wrapping is based on QtJambi, which is now 
 dead, but anyway it's easy with hindsight isn't it.

 Is anyone else interested and can anyone help me with polishing 
 it? It needs testing, trying out on Windows, and some 
 improvements to the build system. I have very little time ATM 
 but it would be good to capture where I've got to so that 
 others could pick it up or just experiment with D and Qt.

 regards
 Abdulhaq


Hi, my story is similar to yours.
but anyway long story short,
i recently managed to get it compiling again with qt 4.8 and dmd 
2.063.2.
https://bitbucket.org/michaelc37/qtd-experimental

i think for the QRect problem i ended up passing pointers, i also 
updated alot of the examples.

i'd like to have a look at your work where can i find it?.
Oct 13 2013
parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
On Sunday, 13 October 2013 at 20:41:01 UTC, michaelc37 wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Hi guys

 a few months ago I tried to find working bindings for Qt and 
 the best I could see was qtd. I tried compiling it but it 
 didn't go too well on my Linux 64bit machine, and saw in the 
 forums that the original developers had ceased maintaining it. 
 Because I have been using Qt for around 10 years or so now 
 (mainly from python but a little C++ too) I had a go at 
 getting it to work again.

 It took a few weekends but I got the main examples going 
 (Core, GUI, XML etc) with Qt 4.8 and 2.062. I felt that I was 
 having to do some rewinding of where the original developers 
 were going (it seemed that they were trying to take QRect et 
 al down the struct route, but my to my newbie eyes it seemed 
 doomed because it was making assumptions about the way the C++ 
 and D compilers were laying out the struct data that didn't 
 work on my machine - but I could be wrong about that). Anyway 
 I treated it as an educational exercise and make QRect et al. 
 regular classes, and got it generally working again.

 Then real life took over again and I had to shelve the 
 project, but now I have a little spare time again. I suspect 
 there are other developers such as myself out there who are 
 keen to try D but would like to use it with Qt, so I thought I 
 would let you know what I had done in case others were 
 interested. I'm kind of hoping that someone will say that the 
 job is already done, but I suspect that is not the case.

 The original developers did a really great job of the wrapping 
 and left the build system in a really good state too. However, 
 there seems to be very little testing other than the standard 
 qt examples themselves, so I can't be sure exactly where the 
 wrapping stands. Although the original developers felt that it 
 had some way to go before being really useful, it seems to me 
 that they had achieved more than that and that some would want 
 to use it as it stood.

 Unfortunately the wrapping is based on QtJambi, which is now 
 dead, but anyway it's easy with hindsight isn't it.

 Is anyone else interested and can anyone help me with 
 polishing it? It needs testing, trying out on Windows, and 
 some improvements to the build system. I have very little time 
 ATM but it would be good to capture where I've got to so that 
 others could pick it up or just experiment with D and Qt.

 regards
 Abdulhaq


 Hi, my story is similar to yours.
 but anyway long story short,
 i recently managed to get it compiling again with qt 4.8 and 
 dmd 2.063.2.
 https://bitbucket.org/michaelc37/qtd-experimental

 i think for the QRect problem i ended up passing pointers, i 
 also updated alot of the examples.

 i'd like to have a look at your work where can i find it?.


Hah, sounds like we did exactly the same thing :-) ! I haven't 
uploaded the code anywhere yet, I was waiting to see if anyone 
was interested...

I also ran into a problem (I think I remember correctly) in the 
QMetaTypeImpl.d area, worrying about code like:

// COMPILER BUG: cannot put this inside 
qRegisterMetaTypeStreamOperators
// COMPILER BUG 2: cannot use extern(C) with templated functions: 
extern(C) void foo(T)(){}
private template streamOpShim(alias op)
{
     extern(C) void streamOpShim()
     {
         asm
         {
             naked;
             push   EBP;
             mov    EBP, ESP;
             mov    EAX, 0x8[EBP];
             push   EAX;
             mov    EAX, 0xC[EBP];
             call   op;
             leave;
             ret;
         }
     }
}


as to whether it would work in 64bit or not? I think I came to 
the conclusion that this was a very minor part of Qt and not to 
worry about it...

Coming back to the code now I think i'm going to have to read the 
D book again before I have another stab at it...
Oct 13 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 13 October 2013 at 20:52:31 UTC, Abdulhaq wrote:

 On Sunday, 13 October 2013 at 20:41:01 UTC, michaelc37 wrote:

 https://bitbucket.org/michaelc37/qtd-experimental
 […]


 Hah, sounds like we did exactly the same thing :-) ! I haven't 
 uploaded the code anywhere yet, I was waiting to see if anyone 
 was interested...


Okay, so what do you guys think about starting an 
"unofficial-official" (I can't speak for Eldar and Max, the main 
authors of QtD, but you have my blessing as a contributor of the 
project) QtD revival repository on GitHub to coordinate the 
efforts?

I can set you up with access to github.com/qtd if you want.

David
Oct 13 2013
next sibling parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Sunday, 13 October 2013 at 21:28:20 UTC, David Nadlinger wrote:

 On Sunday, 13 October 2013 at 20:52:31 UTC, Abdulhaq wrote:

 On Sunday, 13 October 2013 at 20:41:01 UTC, michaelc37 wrote:

 https://bitbucket.org/michaelc37/qtd-experimental
 […]


 Hah, sounds like we did exactly the same thing :-) ! I haven't 
 uploaded the code anywhere yet, I was waiting to see if anyone 
 was interested...


 Okay, so what do you guys think about starting an 
 "unofficial-official" (I can't speak for Eldar and Max, the 
 main authors of QtD, but you have my blessing as a contributor 
 of the project) QtD revival repository on GitHub to coordinate 
 the efforts?

 I can set you up with access to github.com/qtd if you want.

 David


I recommend to dump it and start from scratch. A clang-based 
generator would be an interesting option to explore. Or, if you 
want to preserve your sanity, just write Qt applications in 
C++/QML.
Oct 14 2013
next sibling parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
On Monday, 14 October 2013 at 09:03:44 UTC, Max Samukha wrote:

 On Sunday, 13 October 2013 at 21:28:20 UTC, David Nadlinger

 Okay, so what do you guys think about starting an 
 "unofficial-official" (I can't speak for Eldar and Max, the 
 main authors of QtD, but you have my blessing as a contributor 
 of the project) QtD revival repository on GitHub to coordinate 
 the efforts?

 I can set you up with access to github.com/qtd if you want.

 David


 I recommend to dump it and start from scratch. A clang-based 
 generator would be an interesting option to explore. Or, if you 
 want to preserve your sanity, just write Qt applications in 
 C++/QML.


Hi Max, so why dump it? I can see a few reasons why you might
propose that:

1) You think it's a dead end because QtJambi is dead, so it would
be problematic to move it forward with new versions of Qt
2) There are some problems with the architecture of the binding
that you're aware of that would prevent it from working reliably

For (1), I think even only having 4.8 is still a real asset. I
don't know the code base really well (but spent a fair amount of
time with it, and know the PyQt technology fairly well too) so
can't speak to (2) but if you had specific concerns it would be
very interesting to know what they were.

 From my testing it seems to me that a lot is working, enough to
write useful GUIs in it - tell me what I'm missing (a lot, I
know, but is anything really fatally flawed)?
Oct 14 2013
parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Monday, 14 October 2013 at 09:45:18 UTC, Abdulhaq wrote:

 I recommend to dump it and start from scratch. A clang-based 
 generator would be an interesting option to explore. Or, if 
 you want to preserve your sanity, just write Qt applications 
 in C++/QML.


 Hi Max, so why dump it? I can see a few reasons why you might
 propose that:

 1) You think it's a dead end because QtJambi is dead, so it 
 would
 be problematic to move it forward with new versions of Qt


That is one reason. Also, QtJambi is based on a limited and 
outdated C++ parser, and we had problems getting necessary 
information from it. When Qt moves to C++11, the situation will 
get worse. So I think it is reasonable to switch to clang soon.


 2) There are some problems with the architecture of the binding
 that you're aware of that would prevent it from working reliably

 For (1), I think even only having 4.8 is still a real asset. I
 don't know the code base really well (but spent a fair amount of
 time with it, and know the PyQt technology fairly well too) so
 can't speak to (2) but if you had specific concerns it would be
 very interesting to know what they were.

 From my testing it seems to me that a lot is working, enough to
 write useful GUIs in it - tell me what I'm missing (a lot, I
 know, but is anything really fatally flawed)?


Well, you can use the bindings for simple short-living utilities 
if you don't mind occasional memory leaks and crashes.

Long story short, D allows for two approaches to bindings like 
QtD:

1. The traditional one is to allocate "shells" on GC heap and 
have a set of manually specified rules for ownership transfers 
and reference count adjustments.
2. The other is more interesting - abandon the idea of 
reference/ownership annotations and go with semi-automatic memory 
management as it is in Qt, with no reliance on the GC.

At some point I wanted to switch to 2 completely, so QtD is 
somewhere between 1 and 2, quite a mess.
Oct 15 2013
next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Tuesday, 15 October 2013 at 09:38:15 UTC, Max Samukha wrote:

 Long story short, D allows for two approaches to bindings like 
 QtD:

 1. The traditional one is to allocate "shells" on GC heap and 
 have a set of manually specified rules for ownership transfers 
 and reference count adjustments.
 2. The other is more interesting - abandon the idea of 
 reference/ownership annotations and go with semi-automatic 
 memory management as it is in Qt, with no reliance on the GC.

 At some point I wanted to switch to 2 completely, so QtD is 
 somewhere between 1 and 2, quite a mess.


This is a really interersting point, and the part of desiging the 
API I found the most difficult. How do you write an interface for 
Qt in D that is both polymorphic and avoids memory management 
problems? For instance, in PyQt and PySide, you can have objects 
vanish because you didn't keep a reference to them, even though 
some other part of Qt itself might own a reference to the object.

I couldn't think of a way to do it myself which was elegant.
Oct 15 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/15/13, w0rp <devw0rp gmail.com> wrote:

 I couldn't think of a way to do it myself which was elegant.


Perhaps you can pin the object and hook into the C++ destructor somehow?
Oct 15 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-15 17:55, w0rp wrote:


 This is a really interersting point, and the part of desiging the API I
 found the most difficult. How do you write an interface for Qt in D that
 is both polymorphic and avoids memory management problems? For instance,
 in PyQt and PySide, you can have objects vanish because you didn't keep
 a reference to them, even though some other part of Qt itself might own
 a reference to the object.

 I couldn't think of a way to do it myself which was elegant.


In D, using the GC, you can call GC.addRoot to avoid that problem.

-- 
/Jacob Carlborg
Oct 15 2013
parent reply "w0rp" <devw0rp gmail.com> writes:
On Wednesday, 16 October 2013 at 06:53:24 UTC, Jacob Carlborg 
wrote:

 In D, using the GC, you can call GC.addRoot to avoid that 
 problem.


Yes, I was thinking of using core.memory stuff to stop things 
from being collected, or perhaps scan inside Qt memory. For 
instance, you could store a class pointer inside of a QObject 
with setProperty. One option is to have QObject in D hold an 
array of pointers for keeping references to children, etc. There 
are some tricky parts.

---
// Okay, this is a root object, when do we collect this?
auto widget = new QWidget();

// This is just a free object, not attached to anything.
// Clearly we can collect this.
auto label = new QLabel("Hello!");

auto layout = new QHBoxLayout;

layout.addWidget(label);

// Wait, now label implicitly becomes a child object of widget.
// its memory is now managed by that, so when do we collect it?
widget.setLayout(layout);

// Does this work?
assert(label.parent is widget);
---

So in other words, I haven't yet reached a point where I think, 
"Yes, I have covered every case and I'm happy."
Oct 16 2013
next sibling parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Wednesday, 16 October 2013 at 07:25:08 UTC, w0rp wrote:

 On Wednesday, 16 October 2013 at 06:53:24 UTC, Jacob Carlborg 
 wrote:

 In D, using the GC, you can call GC.addRoot to avoid that 
 problem.


 Yes, I was thinking of using core.memory stuff to stop things 
 from being collected, or perhaps scan inside Qt memory. For 
 instance, you could store a class pointer inside of a QObject 
 with setProperty. One option is to have QObject in D hold an 
 array of pointers for keeping references to children, etc. 
 There are some tricky parts.

 ---
 // Okay, this is a root object, when do we collect this?
 auto widget = new QWidget();

 // This is just a free object, not attached to anything.
 // Clearly we can collect this.
 auto label = new QLabel("Hello!");

 auto layout = new QHBoxLayout;

 layout.addWidget(label);

 // Wait, now label implicitly becomes a child object of widget.
 // its memory is now managed by that, so when do we collect it?
 widget.setLayout(layout);

 // Does this work?
 assert(label.parent is widget);
 ---

 So in other words, I haven't yet reached a point where I think, 
 "Yes, I have covered every case and I'm happy."


I've ended up with a system that would not allocate Qt objects on 
the GC heap at all:

// This would be destroyed at the end of the scope,
auto widget = scoped!QWidget;

// Or, if we allocate the object on heap, we should care
// to destroy it unless Qt takes ownership at some point after
// construction.
auto widget = make!QWidget;
...
dispose(widget);

auto widget = make!QLabel("Hello!");
auto layout = make!QHBoxLayout;

// Safe to pass ownership to parent because no GC is involved.
layout.addWidget(label);
// ditto
widget.setLayout(layout);


// This would work because references to polymorphic Qt objects 
are
// implemented as tagged pointers, and in this case
// both references would point to the same C++ object.
assert(label.parent is widget);

In other words, you manage memory the same way you do in Qt.

Advantages:
- Noticeable simplification of the generator and bindings.
- Performance - no redundant copies, hash lookups, etc.
- Fewer problems with multithreading.

Disadvantages:
- You have to be as careful about memory management as you are in 
Qt.
- Implementation requires a debugged D compiler, which does not 
exist yet. :)

An interesting endeavor would be to figure out whether things 
could be simplified with "interface(C++)".
Oct 16 2013
parent reply "w0rp" <devw0rp gmail.com> writes:
On Wednesday, 16 October 2013 at 09:56:21 UTC, Max Samukha wrote:

 On Wednesday, 16 October 2013 at 07:25:08 UTC, w0rp wrote:

 On Wednesday, 16 October 2013 at 06:53:24 UTC, Jacob Carlborg 
 wrote:

 In D, using the GC, you can call GC.addRoot to avoid that 
 problem.


 Yes, I was thinking of using core.memory stuff to stop things 
 from being collected, or perhaps scan inside Qt memory. For 
 instance, you could store a class pointer inside of a QObject 
 with setProperty. One option is to have QObject in D hold an 
 array of pointers for keeping references to children, etc. 
 There are some tricky parts.

 ---
 // Okay, this is a root object, when do we collect this?
 auto widget = new QWidget();

 // This is just a free object, not attached to anything.
 // Clearly we can collect this.
 auto label = new QLabel("Hello!");

 auto layout = new QHBoxLayout;

 layout.addWidget(label);

 // Wait, now label implicitly becomes a child object of widget.
 // its memory is now managed by that, so when do we collect it?
 widget.setLayout(layout);

 // Does this work?
 assert(label.parent is widget);
 ---

 So in other words, I haven't yet reached a point where I 
 think, "Yes, I have covered every case and I'm happy."


 I've ended up with a system that would not allocate Qt objects 
 on the GC heap at all:

 // This would be destroyed at the end of the scope,
 auto widget = scoped!QWidget;

 // Or, if we allocate the object on heap, we should care
 // to destroy it unless Qt takes ownership at some point after
 // construction.
 auto widget = make!QWidget;
 ...
 dispose(widget);

 auto widget = make!QLabel("Hello!");
 auto layout = make!QHBoxLayout;

 // Safe to pass ownership to parent because no GC is involved.
 layout.addWidget(label);
 // ditto
 widget.setLayout(layout);


 // This would work because references to polymorphic Qt objects 
 are
 // implemented as tagged pointers, and in this case
 // both references would point to the same C++ object.
 assert(label.parent is widget);

 In other words, you manage memory the same way you do in Qt.

 Advantages:
 - Noticeable simplification of the generator and bindings.
 - Performance - no redundant copies, hash lookups, etc.
 - Fewer problems with multithreading.

 Disadvantages:
 - You have to be as careful about memory management as you are 
 in Qt.
 - Implementation requires a debugged D compiler, which does not 
 exist yet. :)

 An interesting endeavor would be to figure out whether things 
 could be simplified with "interface(C++)".



There's one very big disadvantage there, I think. It looks ugly. 
I do have to point out that this opinion somewhat stems from me 
just not liking 'scoped.' I think the above example just makes me 
think, "The best solution has not yet been found." Again, I don't 
know what that is yet.
Oct 22 2013
parent "Max Samukha" <maxsamukha gmail.com> writes:
On Tuesday, 22 October 2013 at 21:01:49 UTC, w0rp wrote:

 On Wednesday, 16 October 2013 at 09:56:21 UTC, Max Samukha 
 wrote:

 On Wednesday, 16 October 2013 at 07:25:08 UTC, w0rp wrote:

 On Wednesday, 16 October 2013 at 06:53:24 UTC, Jacob Carlborg 
 wrote:

 In D, using the GC, you can call GC.addRoot to avoid that 
 problem.


 Yes, I was thinking of using core.memory stuff to stop things 
 from being collected, or perhaps scan inside Qt memory. For 
 instance, you could store a class pointer inside of a QObject 
 with setProperty. One option is to have QObject in D hold an 
 array of pointers for keeping references to children, etc. 
 There are some tricky parts.

 ---
 // Okay, this is a root object, when do we collect this?
 auto widget = new QWidget();

 // This is just a free object, not attached to anything.
 // Clearly we can collect this.
 auto label = new QLabel("Hello!");

 auto layout = new QHBoxLayout;

 layout.addWidget(label);

 // Wait, now label implicitly becomes a child object of 
 widget.
 // its memory is now managed by that, so when do we collect 
 it?
 widget.setLayout(layout);

 // Does this work?
 assert(label.parent is widget);
 ---

 So in other words, I haven't yet reached a point where I 
 think, "Yes, I have covered every case and I'm happy."


 I've ended up with a system that would not allocate Qt objects 
 on the GC heap at all:

 // This would be destroyed at the end of the scope,
 auto widget = scoped!QWidget;

 // Or, if we allocate the object on heap, we should care
 // to destroy it unless Qt takes ownership at some point after
 // construction.
 auto widget = make!QWidget;
 ...
 dispose(widget);

 auto widget = make!QLabel("Hello!");
 auto layout = make!QHBoxLayout;

 // Safe to pass ownership to parent because no GC is involved.
 layout.addWidget(label);
 // ditto
 widget.setLayout(layout);


 // This would work because references to polymorphic Qt 
 objects are
 // implemented as tagged pointers, and in this case
 // both references would point to the same C++ object.
 assert(label.parent is widget);

 In other words, you manage memory the same way you do in Qt.

 Advantages:
 - Noticeable simplification of the generator and bindings.
 - Performance - no redundant copies, hash lookups, etc.
 - Fewer problems with multithreading.

 Disadvantages:
 - You have to be as careful about memory management as you are 
 in Qt.
 - Implementation requires a debugged D compiler, which does 
 not exist yet. :)

 An interesting endeavor would be to figure out whether things 
 could be simplified with "interface(C++)".



 There's one very big disadvantage there, I think. It looks 
 ugly. I do have to point out that this opinion somewhat stems 
 from me just not liking 'scoped.' I think the above example 
 just makes me think, "The best solution has not yet been 
 found." Again, I don't know what that is yet.


There is no best solution. You have to trade off. For my purpose, 
that was the best option, which was maintainable, performant and 
correct (apparenty). I do not care much about how it looks, given 
that it is concise. Some don't like the look of chinese 
hieroglyphs or black skin. I for one don't see much beauty in 
"new". Anyway, the project QtD was intended for was cancelled 
long ago, so you are free to transform it according to yor vision.
Oct 22 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/16/13, w0rp <devw0rp gmail.com> wrote:

 or perhaps scan inside Qt memory.


I've never managed to make this work in some C++ libs I've tried to
wrap. I think it's because the D GC probably knows which memory it
allocated and will not scan pointers to memory it did not allocate.
That's just a guess though.
Oct 16 2013
prev sibling parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Tuesday, 15 October 2013 at 09:38:15 UTC, Max Samukha wrote:

 On Monday, 14 October 2013 at 09:45:18 UTC, Abdulhaq wrote:

 I recommend to dump it and start from scratch. A clang-based 
 generator would be an interesting option to explore. Or, if 
 you want to preserve your sanity, just write Qt applications 
 in C++/QML.


 Hi Max, so why dump it? I can see a few reasons why you might
 propose that:

 1) You think it's a dead end because QtJambi is dead, so it 
 would
 be problematic to move it forward with new versions of Qt


 That is one reason. Also, QtJambi is based on a limited and 
 outdated C++ parser, and we had problems getting necessary 
 information from it. When Qt moves to C++11, the situation will 
 get worse. So I think it is reasonable to switch to clang soon.


OK I see (unfortunately !)


 Long story short, D allows for two approaches to bindings like 
 QtD:

 1. The traditional one is to allocate "shells" on GC heap and 
 have a set of manually specified rules for ownership transfers 
 and reference count adjustments.
 2. The other is more interesting - abandon the idea of 
 reference/ownership annotations and go with semi-automatic 
 memory management as it is in Qt, with no reliance on the GC.

 At some point I wanted to switch to 2 completely, so QtD is 
 somewhere between 1 and 2, quite a mess.


I did notice when in the code that it was partially in a 
transitional state - now I know what you were doing!

I have to confess that in the light of this and some of your 
other posts, the siren call of 'start again' is singing in my ear.
Oct 16 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-14 11:03, Max Samukha wrote:


 I recommend to dump it and start from scratch. A clang-based generator
 would be an interesting option to explore. Or, if you want to preserve
 your sanity, just write Qt applications in C++/QML.


I already have a Clang based tool, DStep, but that's only for C and 
Objective-C. It could be extended to support C++ as well.

https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg
Oct 14 2013
parent "Max Samukha" <maxsamukha gmail.com> writes:
On Monday, 14 October 2013 at 11:35:05 UTC, Jacob Carlborg wrote:

 On 2013-10-14 11:03, Max Samukha wrote:


 I recommend to dump it and start from scratch. A clang-based 
 generator
 would be an interesting option to explore. Or, if you want to 
 preserve
 your sanity, just write Qt applications in C++/QML.


 I already have a Clang based tool, DStep, but that's only for C 
 and Objective-C. It could be extended to support C++ as well.

 https://github.com/jacob-carlborg/dstep


Nice! That may come in handy some day.
Oct 15 2013
prev sibling parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
On Sunday, 13 October 2013 at 21:28:20 UTC, David Nadlinger wrote:

 On Sunday, 13 October 2013 at 20:52:31 UTC, Abdulhaq wrote:

 On Sunday, 13 October 2013 at 20:41:01 UTC, michaelc37 wrote:

 https://bitbucket.org/michaelc37/qtd-experimental
 […]


 Hah, sounds like we did exactly the same thing :-) ! I haven't 
 uploaded the code anywhere yet, I was waiting to see if anyone 
 was interested...


 Okay, so what do you guys think about starting an 
 "unofficial-official" (I can't speak for Eldar and Max, the 
 main authors of QtD, but you have my blessing as a contributor 
 of the project) QtD revival repository on GitHub to coordinate 
 the efforts?

 I can set you up with access to github.com/qtd if you want.

 David


I think it would be worthwhile to try and get the code as it 
stands working cross-platform, so I think Michael and I should 
talk and try and merge our work somehow, then perhaps committing 
it to some sort of QtD revival repo would be worth doing.
Oct 14 2013
parent reply "michaelc37" <michaelc37 msn.com> writes:
On Monday, 14 October 2013 at 12:32:18 UTC, Abdulhaq wrote:

 On Sunday, 13 October 2013 at 21:28:20 UTC, David Nadlinger 
 wrote:

 On Sunday, 13 October 2013 at 20:52:31 UTC, Abdulhaq wrote:

 On Sunday, 13 October 2013 at 20:41:01 UTC, michaelc37 wrote:

 https://bitbucket.org/michaelc37/qtd-experimental
 […]


 Hah, sounds like we did exactly the same thing :-) ! I 
 haven't uploaded the code anywhere yet, I was waiting to see 
 if anyone was interested...


 Okay, so what do you guys think about starting an 
 "unofficial-official" (I can't speak for Eldar and Max, the 
 main authors of QtD, but you have my blessing as a contributor 
 of the project) QtD revival repository on GitHub to coordinate 
 the efforts?

 I can set you up with access to github.com/qtd if you want.

 David


 I think it would be worthwhile to try and get the code as it 
 stands working cross-platform, so I think Michael and I should 
 talk and try and merge our work somehow, then perhaps 
 committing it to some sort of QtD revival repo would be worth 
 doing.


Yes that's a good idea.. Should we move  github from the current 
main bitbucket repo, then reapply changes after some review ?
Oct 14 2013
parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Monday, 14 October 2013 at 13:01:48 UTC, michaelc37 wrote:

 On Monday, 14 October 2013 at 12:32:18 UTC, Abdulhaq wrote:

 On Sunday, 13 October 2013 at 21:28:20 UTC, David Nadlinger 
 wrote:

 On Sunday, 13 October 2013 at 20:52:31 UTC, Abdulhaq wrote:

 On Sunday, 13 October 2013 at 20:41:01 UTC, michaelc37 wrote:

 https://bitbucket.org/michaelc37/qtd-experimental
 […]


 Hah, sounds like we did exactly the same thing :-) ! I 
 haven't uploaded the code anywhere yet, I was waiting to see 
 if anyone was interested...


 Okay, so what do you guys think about starting an 
 "unofficial-official" (I can't speak for Eldar and Max, the 
 main authors of QtD, but you have my blessing as a 
 contributor of the project) QtD revival repository on GitHub 
 to coordinate the efforts?

 I can set you up with access to github.com/qtd if you want.

 David


 I think it would be worthwhile to try and get the code as it 
 stands working cross-platform, so I think Michael and I should 
 talk and try and merge our work somehow, then perhaps 
 committing it to some sort of QtD revival repo would be worth 
 doing.


 Yes that's a good idea.. Should we move  github from the 
 current main bitbucket repo, then reapply changes after some 
 review ?


I've not used GitHub before, until now I've been stuck on 
Subversion  - I'll take your lead on what's the best way to go 
about it. Email me on alynch4047 at gmail and we can take the 
merge forward, then we can let David know when we're ready.
Oct 14 2013
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Anyway I treated it as an educational exercise and make QRect 
 et al. regular classes, and got it generally working again.


QRect as a class doesn't sound good: the class layouts are 
incompatible between D and C++. If you want to mimic C++ data 
layout, you should do it manually - use structs with pads or 
translate the data at the border of languages.
Oct 14 2013
parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
On Monday, 14 October 2013 at 18:27:52 UTC, Kagamin wrote:

 On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote:

 Anyway I treated it as an educational exercise and make QRect 
 et al. regular classes, and got it generally working again.


 QRect as a class doesn't sound good: the class layouts are 
 incompatible between D and C++. If you want to mimic C++ data 
 layout, you should do it manually - use structs with pads or 
 translate the data at the border of languages.


In the binding my making QRect/QLine/QPoint bound as a class 
means that data access is through methods and so always works 
regardless of the way the compiler lays out the data - whereas it 
was previously being treated as a struct, which didn't work on my 
64bit machine. I want to keep the wrapper as simple as possible 
(personally) so avoid padding data etc. I also wanted something 
quick to do as I had no idea how much other work would be 
required before anything worked at all.

I'm not a C++ developer (I read it a fair amount but write very 
little) but my understanding of what was happening is that in the 
developers' environment the C++ and D compilers laid out the 
class the same, wheres on 64bit Linux I found that (after a lot 
of time debugging) that while things compiled, they didn't work 
due to corruption in QRect when passing through the wrapper.

I guess the original developers made QRect/QLine/QPoint structs 
for performance reasons, but in my own Qt experience you don't 
actually deal with that many instances of these types so 
application performance is not sensitive to how they are wrapped 
(of course YMMV).

Ultimately, it didn't work for me before whereas it does now :-)
Oct 14 2013
parent "Kagamin" <spam here.lot> writes:
On Monday, 14 October 2013 at 19:11:39 UTC, Abdulhaq wrote:

 Ultimately, it didn't work for me before whereas it does now :-)


It may fail for someone else similarly to how you describe it 
worked in other developers' setup.
Oct 14 2013