Qt bindings for D

w0rp devw0rp at gmail.com
Mon Oct 14 14:39:10 PDT 2013


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.


More information about the Digitalmars-d mailing list