Andrei Alexandrescu Wrote:
> Eldar Insafutdinov wrote:
> > Right now we are working on a next QtD version. We dropped support
> > for D1, it is D2 only. I believe Qt suits all your requirements very
> > well. It's performant - we try to emulate as many C++ types using D
> > structs as possible, for drawing purposes. So types like QPoint - are
> > D structs and for drawing lines you can pass D array directly. No
> > perfromance hit. But of course we cannot avoid all of them, it is
> > still a binding. Regarding the license, Qt itself is LGPLed, QtD is
> > boost. you don't have to put any attribution. About stability of APIs
> > - Qt4 is stable within the major version. At the moment we are
> > working on signals/slots implementation. It is mostly complete, but
> > syntax may change. It will hopefully change once and stay forever.
> >
> > I would say that QtD is in the state close to that of D2, almost
> > there, but not quite ready yet. But we intend to release the next
> > version, which will be ready to use earlier than D2 anyway, I would
> > say within a month.
>
> I salute the decision of going with D2, as well as that of using the
> Boost license. If there is anything in the language that prevents you
> from getting things done, please let us know. The availability of QtD
> concurrently with that of D2 will hopefully push both forward.
>
> Andrei
Thanks for cooperation. I don't want to sound like I've given the right to ask for features, because I am working on a particular D project. But at the same time, indeed, while working on this project I found many things that I would like to be improved. Here are some of them:
1) You may know the concept of signals and slots in Qt. Consider the following snippet:
class Test : QObject
{
mixin Signal!("signal_1(string)");
mixin Slot!("slot_1(string str)");
void slot_1(string str)
{
writefln("slot_1 invoked with ~ " str);
}
mixin Q_OBJECT;
}
In Qt objects, that inherit from QObject are capable of having signals and slots and participate in connections. In the current scheme mixins of Signal and Slot template mix some static information into the class. The class is then scanned when Q_OBJECT template is mixed in and the proper meta-information is generated to register signals and slots in the Qt type system.
As you see, this declaration is a bit ugly. In particular defining a slot requires to duplicate its signature in a mixin. What would really be awesome is a mechanism allowing something like:
@Slot
void slot_1(string str)
{
writefln("slot_1 invoked with " ~ str);
}
I.e we need annotations. But I am not sure how this will work. One of the possible solutions will be that @Slot expands into mixin Slot!(symbol, AnnotationArg1, ...).
But I have to say, that expanding annotations into mixins might not be a good idea. Annotations could rather be implemented by aggregating the data with symbols instead. I think it will be more clean than the current scheme we chose with mixing in and scanning data. Instead you have some data aggregated with declarations. Using compile time reflection you iterate over the symbols, look for annotations, extract them and do whatever you want with it. Say if we introduce traits(getAnnotations, symbol) feature and it will return a construct like StaticTuple!(SealedTuple!("annotationName", AnnotationArg1, ...), ...); it will be sufficient. We should discuss it more anyway.
2) Second problem in this declaration is that in order for Q_OBJECT template to see all signal and slot declaration you have to put the mixin after all of them, like in example. This is absolutely a stupid requirement. Again it could be solved either by annotations:
@Q_OBJECT
class Test : QObject
{ ... }
which will again expand into a mixin in the class body after all of the declarations,
or by the feature you suggested a while ago - mixin (Derived), which will mix in some stuff to all sub-classes of QObject automatically.
3) To continue the first paragraph signals should also get some love. If we have this for slots:
@Slot
void slot_1(string str)
{
...
}
I would also like to have something like:
@Signal
void signal_1();
What it will effectively means, is that we are declaring a method without a body and aggregate some meta data with it using annotation. The body for the signal instead of being generated by the mixin Signal!(...) like in the first snippet, will be generated at the very end by mixin Q_OBJECT (or with a mixin Derived)
Essentially we should allow separating function declaration and definition to allow that, currently dmd just asserts trying to compile this:
class Test
{
void foo();
void foo() {}
}
So the final refined declaration of a class with a signal and a slot from the first snippet using proper annotations, mixin Derived in the base class and allowing for separating function declaration and definition will look like:
class Test : QObject
{
@Signal
void signal_1(string);
@Slot
void slot_1(string str)
{
writefln("slot_1 invoked with " ~ str);
}
}
Much nicer, isn't it?
4) __traits should access the data mixed in by template mixins. Otherwise we have to use dirty template trickery.
5) As QtD uses templates extensively, it would be really helpful if the compiler gave better error messages about template instantiation errors. Specifically, static assert(false, ) is often used to give the user a message about the error but it is sometimes very hard to find the place of outer instantiation. Propagating the FILE_ and __LINE__ to nested instantiations is impractical. There has been this patch by Don for a long time that fixes the 'static assert' issue: http://d.puremagic.com/issues/show_bug.cgi?id=2816. We'd really like to have it applied. See also http://d.puremagic.com/issues/show_bug.cgi?id=2902, http://d.puremagic.com/issues/show_bug.cgi?id=2510.
6) Various, various compiler bugs. I'm not joking here, I hit dmd bugs every single day I work on qtd. It makes it very difficult to cut down to sensible testcases, because of the size of the library. I filed some bugs, I used all my votes in bugzilla, but neither of those got any update within last 2 months. That's a pity. I am sure many other people have similar experience.
The main one is probably forward references bug. That's why I have to use patched version of dmd (done not by me). Work on it is still in progress, and when the author of the patches finishes it and submits them to the bugzilla, we would need apply them somehow, as otherwise official dmd will not compile QtD.