D Binding to GUI libraries [was Interesting Observation from JAXLondon]

[Atila Neves]

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.