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

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

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.

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.

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?

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 ?

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.

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.

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

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.