The Current Status of DQt

[w0rp via Digitalmars-d]

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