Le 04/05/2014 11:21, "Marc Schütz" <schue...@gmx.net>" a écrit :
A "meta" question, not related to your specific implementation:While Qt is certainly the most powerful and comprehensive portable GUI framework, it also contains lots of code that's not related to user interfaces: strings, multi-threading support, file abstractions, containers, databases interfaces, etc. In short: Things which properly should be part of the standard library, but aren't (widely) available, or not working well enough in C++. Now, Qt depends on those, and if you want to interact with it, you need to use them in your own code. Doesn't that cause a lot of friction? Just as a random example, QListView can take its elements from a data source ("model"). But in D, that data source might be idiomatically implemented as a range, so it has to be adapted first. Or, a more frequent thing: char[] vs. QString. Could it be a better strategy to only re-use low-level functionality of Qt internally, but provide more idiomatic public D interfaces for it?
With a friend we created the DQuick project cause of our major interest of the QtQuick (also called QML) part of Qt framework and also for the reason you invoke. For us phobos already aim to implement same things than QtCore, and wrapping primitive types of Qt seems hard and will introduce design constraint and poor performances. It's certainly bad for a longterm vision.
IMO DQt will be interesting for those looking for a stable GUI library based on widget essentially. DQuick have no chance to be usable in production before years if we continue to develop it. We are back after a long break, it's really hard to stay motivated cause we have some difficulties with points aren't fixed in D, mainly GC issues, signals,... My friend just find get the property binding working in D code, but he doesn't like his code :-).
I see DQt/gtkD and DQuick as complementary projects. I hope we will capable to provide good enough GUI libraries to D community shortly.
