Hello everyone. From time to time, people ask in the newsgroup and also IRC about Qt bindings for D, so I thought it would be a good idea to give people an update on where my own bindings stand. First, if you want to take a look at my code as it stands, you can get it here.

https://github.com/w0rp/dqt

It depends on two other repositories which are also hosted on GitHub, and which are mentioned in the readme. Building dqt itself isn't that great, as I ran into some issues with DUB, but Sönke has since addressed my primary issue, so it may now be possible to build the project with the master branch version of DUB. Here is what I have done.

1. These bindings use SMOKE, which is a library which can be used to generate bindings for C++ libraries. The 'smokeqt' library does a Hell of a lot of work already for me. Everything I have is written in about 99% D. The "just SMOKE" part I have put in a separate repo, and it could potentially be used for wrapping other C++ libraries.
2. The majority of classes from Qt are generated as D classes which wrap around the C++ classes. This allows for polymorphism, at the expense of some additional resource management at times. (You can disable garbage collection and let Qt take over.)
3. Calling virtual method overrides from C++ isn't done yet, but I pretty much know how to do it, and there is some code in place which does about half of the job.
4. You can draw windows and so on with a DQt program. (I drew a gridlayout with a few buttons for a calculator successfully)

There are some important things left to do.

1. I have not accounted for multiple inheritance yet, which Qt uses. My idea was to nominate one class as the concrete class which is inherited (QObject) and then turn other classes into interaces which have seperate classes for implementation. (QPaintDevice)
2. I have not yet implemented signals and slots. Two options for this involve generating QMetaObject instances for classes, possibly via template mixins, which do what 'moc' does for C++. A second option is to use Qt5 for the library and to force all signals and slots behaviour to go through functions, as Qt5 can use function pointers as slots. (I prefer option 2.)

So, I am eager to hear what people think about all of this. Does anyone like the work that I have done, and will it be useful? Have I committed some terrible crime against nature, for which I must be punished? Does anyone have any ideas about things that could be improved, or where to go next? Please, let me know.

My progress has been somewhat slow in writing all of this, as I have been writing it mostly in the evenings, moslty during weekdays, after my day job. I've also been running into problems for which there are no easy answers, possibly no documentation for, and so on. So a great deal of my time has been spent more on thinking of what to do next, rather than writing anything. (It took me possibly months to come up with the resource management scheme that I have now.)

On Sat, 03 May 2014 11:00:37 +0000
w0rp via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> So, I am eager to hear what people think about all of this. Does anyone like the work that I have done, and will it be useful? Have I committed some terrible crime against nature, for which I must be punished? Does anyone have any ideas about things that could be improved, or where to go next? Please, let me know.

I can't really comment much on your approach or implementation, because I haven't looked at what you've done, and while I do have some experince with Qt, I haven't done a lot with it (and I haven't done a lot with GUI programming in general), so I'm not in a good position to comment on or review a D wrapper for Qt.

That being said, if I were to write a GUI application in either C++ or D, I
would want to use Qt (preferably Qt5). And given what is on my todo list, I
expect that I'll be looking at writing a GUI application in D within a year
or two. So, having a useable wrapper library for Qt in D is something that
I'm very interested in seeing happen. I wasn't aware of your efforts in that
regard (I was just aware of QtD, though it's not clear to me how actively
developed it is at this point, since it was my understanding that the
original devs dropped it, but I know that some folks have repos of it with
more recent changes), but I'm very glad that someone is taking up this torch,
and I wish you the best of luck with it. I'm just not likely to be of much
help in reviewing or critiquing it at this point. However, there are quite
a few folks around here who are not only much more familiar with GUI
development but who are also very opinionated on the matter, so hopefully
some of them will be able to chime in with useful insights.

- Jonathan M Davis

On Sat, 2014-05-03 at 11:00 +0000, w0rp via Digitalmars-d wrote: […]
> 2. I have not yet implemented signals and slots. Two options for this involve generating QMetaObject instances for classes, possibly via template mixins, which do what 'moc' does for C++. A second option is to use Qt5 for the library and to force all signals and slots behaviour to go through functions, as Qt5 can use function pointers as slots. (I prefer option 2.)

It's Qt, signals and slots are necessary!

>From a personal perspective I only care about Qt5 and in particular QML.

> So, I am eager to hear what people think about all of this. Does anyone like the work that I have done, and will it be useful? Have I committed some terrible crime against nature, for which I must be punished? Does anyone have any ideas about things that could be improved, or where to go next? Please, let me know.

Whilst GtkD works and I am using it for a small GNOME-based project, Qt is a better choice for systems that are to work on GNOME, OSX, KDE, Android, and even Windows. QtD appears to have died, though Michael Crompton has been trying to get it going again: https://bitbucket.org/michaelc37/qtd-experimental

> My progress has been somewhat slow in writing all of this, as I have been writing it mostly in the evenings, moslty during weekdays, after my day job. I've also been running into problems for which there are no easy answers, possibly no documentation for, and so on. So a great deal of my time has been spent more on thinking of what to do next, rather than writing anything. (It took me possibly months to come up with the resource management scheme that I have now.)

I suspect there is a "chicken and egg" situation here: D doesn't have a strong Qt offering, so people do not use D for Qt work, and no-one is using Qt and D so there is no resource to ensure a strong Qt offering for D.

This cycle got broken for Go when Gustavo Niemeyer decided his group in Canonical would use Go and QML and so he created the Go support for QML on company time. He has focussed entirely on support for QML, and not worried about providing a complete Go binding to Qt. Much of it is there, but only with a view to supporting the QML aspects of things. This has meant that Go+QML is really rather good.

I wonder if instead of trying to create a D binding to Qt, DQt (or QtD), following Gustavo's approach with Go and just providing a D binding to QML would get further faster.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

 I think Get experience from QML to create  a D binding to Qt, that is better than binding to QML. the Go's The programming thinking is not same to the C++,and D.

DQt is Working hard more, but has significant effect for D.

DQt is very clear.

I'm intersting for DQt is better than QML.

A "meta" question, not related to your specific implementation:

While Qt is certainly the most powerful and comprehensive portable GUI framework, it also contains lots of code that's not related to user interfaces: strings, multi-threading support, file abstractions, containers, databases interfaces, etc. In short: Things which properly should be part of the standard library, but aren't (widely) available, or not working well enough in C++.

Now, Qt depends on those, and if you want to interact with it, you need to use them in your own code. Doesn't that cause a lot of friction? Just as a random example, QListView can take its elements from a data source ("model"). But in D, that data source might be idiomatically implemented as a range, so it has to be adapted first. Or, a more frequent thing: char[] vs. QString.

Could it be a better strategy to only re-use low-level functionality of Qt internally, but provide more idiomatic public D interfaces for it?

On 03/05/14 13:00, w0rp via Digitalmars-d wrote:
> Hello everyone. From time to time, people ask in the newsgroup and also IRC
> about Qt bindings for D, so I thought it would be a good idea to give people an
> update on where my own bindings stand. First, if you want to take a look at my
> code as it stands, you can get it here.
>
> https://github.com/w0rp/dqt

First of all, it's fantastic that you're working on this.  Many thanks!

I won't comment on the details of the code; it's outside my area of experience, but I do think that Qt support is something that will be very important for adoption of D.

> So, I am eager to hear what people think about all of this. Does anyone like the
> work that I have done, and will it be useful? Have I committed some terrible
> crime against nature, for which I must be punished? Does anyone have any ideas
> about things that could be improved, or where to go next? Please, let me know.

A remark about your README: it lists as dependencies "A recent Qt 4 version, like Qt 4.8".

I think you should be far more explicit, far earlier in the README, about exactly which Qt versions are supported.  Pretty much the first question I had on my mind, clicking on the link to your project, was, "Is this going to support Qt 5.x ... ?"

I also think that a focus on 4.x rather than 5.x is likely to be counter-productive.  5.2+ seems to be where all the interest is these days.

> My progress has been somewhat slow in writing all of this, as I have been
> writing it mostly in the evenings, moslty during weekdays, after my day job.
> I've also been running into problems for which there are no easy answers,
> possibly no documentation for, and so on. So a great deal of my time has been
> spent more on thinking of what to do next, rather than writing anything. (It
> took me possibly months to come up with the resource management scheme that I
> have now.)

I can sympathize with your predicament as I often find myself in the same position.  The good side is that the time spent thinking in this way is usually very productive when one comes to finally sit down and write :-)

On Sunday, 4 May 2014 at 09:21:30 UTC, Marc Schütz wrote:
> A "meta" question, not related to your specific implementation:
>
> While Qt is certainly the most powerful and comprehensive portable GUI framework, it also contains lots of code that's not related to user interfaces: strings, multi-threading support, file abstractions, containers, databases interfaces, etc. In short: Things which properly should be part of the standard library, but aren't (widely) available, or not working well enough in C++.
>
> Now, Qt depends on those, and if you want to interact with it, you need to use them in your own code. Doesn't that cause a lot of friction? Just as a random example, QListView can take its elements from a data source ("model"). But in D, that data source might be idiomatically implemented as a range, so it has to be adapted first. Or, a more frequent thing: char[] vs. QString.
>
> Could it be a better strategy to only re-use low-level functionality of Qt internally, but provide more idiomatic public D interfaces for it?

I'm only interested in getting the GUI parts of Qt to work. A lot of the features of Qt exist I think because there wasn't a reasonable portable alternative in C++ at the time. I think with D, there are or will be better alternatives than what Qt offers for certain things. (Like a threading implementation, for instance.) So my interest in supporting Qt classes only extends as far as getting GUI building to work. So I want to use native D types like 'string' and 'int[]' as much as possible, rather than Qt's types.

I believe that some wrapping can be avoided. I haven't attempted it yet, but I believe that it should be possible to recreate value types from Qt in D, and pass them over such that the data matches up to what C++ expects. Then basic things like what to do with a bunch of QPoint values can be dealt with in idiomatic D ways.

On Sunday, 4 May 2014 at 13:08:38 UTC, Joseph Rushton Wakeling via
> A remark about your README: it lists as dependencies "A recent Qt 4 version, like Qt 4.8".
>
> I think you should be far more explicit, far earlier in the README, about exactly which Qt versions are supported.  Pretty much the first question I had on my mind, clicking on the link to your project, was, "Is this going to support Qt 5.x ... ?"
>
> I also think that a focus on 4.x rather than 5.x is likely to be counter-productive.  5.2+ seems to be where all the interest is these days.

Qt 4.8 support comes largely from what is possible easily now. DQt uses SMOKE to wrap Qt. In particular smokeqt, which produces the SMOKE Qt bindings. You can get smokeqt for Qt 4 straight from most package managers (Arch Linux, Debian, Gentoo, ...) and it's also the current master version of the project on git. Someone has very recently been working on a Qt5 branch for smokeqt, so I expect Qt 5 support to come soon. Qt5 support for smokeqt will directly influcence Qt 5 support in DQt, and I might jump on it early for binding functions as slots. (A Qt 5 feature.)

Qt 4 support basically arises from what is easy to do right now. Supporting Qt 5 doesn't seem that far off. I went with Qt 4 for now because it's easier, and at this stage it's more important to work with something that can actually work and learn from that, than to try and work with something which might not actually work at all.

On Sun, 2014-05-04 at 13:15 +0000, w0rp via Digitalmars-d wrote: […]
> I'm only interested in getting the GUI parts of Qt to work. A lot of the features of Qt exist I think because there wasn't a reasonable portable alternative in C++ at the time. I think with D, there are or will be better alternatives than what Qt offers for certain things. (Like a threading implementation, for instance.) So my interest in supporting Qt classes only extends as far as getting GUI building to work. So I want to use native D types like 'string' and 'int[]' as much as possible, rather than Qt's types.

I guess a dark corner is going to be GUI network applications (which I
have as one of my pet projects). Qt supports GUI and network on the same
event loop, which is both good and terrible. For PyQt5 with a single
thread (and a GIL) it is great. For languages such as D and C++ which
can manage multiple kernel threads on multicore machines I would think
separate even loops would be better (but I don't yet have any data, I am
just beginning to try this idea out – it is likely that many people have
already trodden this route…) For this latter case the D architecture I
have in mind is vibe.d for network and GtkD or QtD^H^H^HDQt for GUI. I
suspect to do this sensibly needs signals for Qt.
[…]
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder