On Monday, 14 October 2013 at 09:45:18 UTC, Abdulhaq wrote:
I recommend to dump it and start from scratch. A clang-based
generator would be an interesting option to explore. Or, if
you want to preserve your sanity, just write Qt applications
in C++/QML.
Hi Max, so why dump it? I can see a few reasons why you might
propose that:
1) You think it's a dead end because QtJambi is dead, so it
would
be problematic to move it forward with new versions of Qt
That is one reason. Also, QtJambi is based on a limited and
outdated C++ parser, and we had problems getting necessary
information from it. When Qt moves to C++11, the situation will
get worse. So I think it is reasonable to switch to clang soon.
2) There are some problems with the architecture of the binding
that you're aware of that would prevent it from working reliably
For (1), I think even only having 4.8 is still a real asset. I
don't know the code base really well (but spent a fair amount of
time with it, and know the PyQt technology fairly well too) so
can't speak to (2) but if you had specific concerns it would be
very interesting to know what they were.
From my testing it seems to me that a lot is working, enough to
write useful GUIs in it - tell me what I'm missing (a lot, I
know, but is anything really fatally flawed)?
Well, you can use the bindings for simple short-living utilities
if you don't mind occasional memory leaks and crashes.
Long story short, D allows for two approaches to bindings like
QtD:
1. The traditional one is to allocate "shells" on GC heap and
have a set of manually specified rules for ownership transfers
and reference count adjustments.
2. The other is more interesting - abandon the idea of
reference/ownership annotations and go with semi-automatic memory
management as it is in Qt, with no reliance on the GC.
At some point I wanted to switch to 2 completely, so QtD is
somewhere between 1 and 2, quite a mess.
