The Current Status of DQt

[via Digitalmars-d]

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?