On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote:
On Saturday, 20 October 2018 at 09:25:58 UTC, Russel Winder
wrote:
On Sat, 2018-10-20 at 08:52 +0000, Gregor Mückl via
Digitalmars-d wrote:
[…]
I periodically look at how I can make use of D for small
projects. Most often, I shy away because I want to build a
GUI and none of the libraries that I can find look mature and
well maintained enough to put my faith in. For C++ there's
Qt, which is *phenomenally* good (despite some warts), but
there's been at least half a dozen attempts at creating D
bindings for that, all in various states of
completion/negligence.
GtkD works very well for me. But I guess GTK+ has a reputation
of not working on Windows and macOS. Once a reputation is
established it is nigh on impossible to refute.
Gtk is clearly working on Windows from a technical point of
view. Gimp on Windows is proof of that. But the look and feel
are too different from what Windows users expect in my eyes and
I did have a few unpleasant experiences with Gtk in the past.
So I personally do not have any real desire to use it. My
encounters with Qt were more involved and generally very
pleasant and successful. I want to stress that this is only my
personal view that I arrived at over the years. Any bias in it
is purely mine.
Qt appears to be C++ battering ram against all other languages
other than Python. Go has failed to get a really good binding,
except perhaps to QML. D has failed to get a really good
binding to Qt or QML. I guess I should check out the Rust
binding, except that I am in the gtk-rs and gstreamer-rs camp
these days on all things GUI.
Qt did have very good bindings to Java in the form of Qt Jambi,
which was commercially developed back in the day by (then)
Trolltech. Unfortunately for me, they killed that product off
just as it reached 1.0. But a lot of the generator code was
reused for PySide which was started around that time. Qt really
depends on the code generated by the moc preprocessor. Even
though the generated code is not really all that complicated,
filling in the same gaps in bindings for other languages is
quite hard. I think that Python has such good bindings only
because both PyQt and PySide were commercially backed from the
start. I can't think of any other currently maintained language
bindings that have that luxury.
Even though web and mobile UIs seem to be the rage at the
moment, I believe a solid support for desktop UIs is very
important for a general purpose language, if it wants to be
successful in the market. D could be well suited for various
kinds of applications in that area, especially those that have
complex logic with some really performance critical parts and
require rich user interfaces. Productivity, CAD, DCC and data
processing/visualization would probably be among the extreme
categories here.
D has always had an excellent story in the "connect to C
linkage libraries", has any of the work in D on C++ linkage
over the last few years changed the landscape so that a D
binding for Qt and QML could be as good as the GtkD binding is
to GTK+?
[…]
Excellent question! All I know is that Binderoo and dpp are two
WIP projects that want to make binding to C++ easier. The
authors are active in the forum, aren't they?
It turns out that translating C++ is *hard*. Partly because the
language is huge and complicated, but also partly because
libclang isn't all it's cracked up to be. But... dpp is probably
a few full work days away from being to #include <vector>.
Hopefully with the translation actually working.
The namespace hack Walter suggested doesn't work in practice, but
now that extern(C++, "ns") is a thing I just need to massively
refactor the code and use that instead.
I've also realised that there are parts of C++ that are probably
unstranslatable no matter what I do. Hopefully a pragmatic "you
can #include <vector> but you can't use std::is_reference from
<type_traits>"* approach will let us call enough of C++ in
practice.
Right now I'm blacklisting several things in <type_traits>...
Atila
* std::is_reference is untranslatable: there are no reference
types in D. It's likely to get used with SFINAE, and while that
is translatable by hand, I have no idea how I'd write an
algorithm to figure out SFINAE when it happens and translate that
to template constraints in D.
