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

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.

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.

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

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

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

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.

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

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?

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.