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.
