The Current Status of DQt

[w0rp via Digitalmars-d]

On Sunday, 4 May 2014 at 09:21:30 UTC, Marc Schütz wrote:
> 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?

I'm only interested in getting the GUI parts of Qt to work. A lot 
of the features of Qt exist I think because there wasn't a 
reasonable portable alternative in C++ at the time. I think with 
D, there are or will be better alternatives than what Qt offers 
for certain things. (Like a threading implementation, for 
instance.) So my interest in supporting Qt classes only extends 
as far as getting GUI building to work. So I want to use native D 
types like 'string' and 'int[]' as much as possible, rather than 
Qt's types.

I believe that some wrapping can be avoided. I haven't attempted 
it yet, but I believe that it should be possible to recreate 
value types from Qt in D, and pass them over such that the data 
matches up to what C++ expects. Then basic things like what to do 
with a bunch of QPoint values can be dealt with in idiomatic D 
ways.