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.
