October 20, 2018
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.

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.

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+?

[…]
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



October 20, 2018
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?
October 20, 2018
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.

Last time I tried to use GTK on windows I had to build i from source myself, from the looks of it that hasn't changed. It has a huge dependency list, and some of those dependencies have their own dependencies. They all have to be built their own different way on Windows. It's a pain in the ass to do, i tried and didn't bother after trying to compile cairo or whatever. Kind of odd they don't have any sort of build script, I guess they just use Mingw which not very many people use.

It may work on Windows, but the amount of effort to set it up is not worth it at all. The developers of the library obviously don't care enough either to try to reduce that barrier. Why not provide a built shared library? Something tells me they haven't even bothered to compile it with MSVC themselves. Their guide to build with MSVC links to a 3+ year old Gnome article where someone not even affiliated with GTK wrote a powershell script to build it with MSVC. The other links to an article that is still using VS 2010 and 2008 for the build.

I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right.


October 20, 2018
On Sat, 2018-10-20 at 12:43 +0000, tide via Digitalmars-d wrote:
> 
[…]
> I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right.

I do not disagree, especially about GTK+ not really being available on Windows and macOS, it is fundamentally a Linux and UNIX framework – I think we can ignore the fact that macOS is sort of FreeBSD in this circumstance due to macOS.

I'd agree Qt is a much better cross-platform GUI framework that GTK+. I've use it with Python very successfully – originally with PySide, then PyQt, but now back with PySide2. I tried QML with Go to move to native code from Python, but it didn't really work for me as yet, though some people gave me a few tips a few weeks back that I haven't followed up on as yet.

wxWidgets seems still to be going though and wxPython is rising as a phoenix . I haven't really used them though but maybe the latest version is worth a whirl.

I guess people doing Qt stuff really do work with C++ if they don't work with Python? I'd call this an opportunity for D. The trick has to be to automate the creation of the binding. I have to admit I do not know what the technique is for PySide2 but PyQt certainly has a system for generation of the binding.

Of course, Rust  https://github.com/rust-qt

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



October 20, 2018
On Saturday, 20 October 2018 at 14:24:56 UTC, Russel Winder wrote:
> On Sat, 2018-10-20 at 12:43 +0000, tide via Digitalmars-d wrote:
>> 
> […]
>> I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right.
>
> I do not disagree, especially about GTK+ not really being available on Windows and macOS, it is fundamentally a Linux and UNIX framework – I think we can ignore the fact that macOS is sort of FreeBSD in this circumstance due to macOS.
>
> I'd agree Qt is a much better cross-platform GUI framework that GTK+. I've use it with Python very successfully – originally with PySide, then PyQt, but now back with PySide2. I tried QML with Go to move to native code from Python, but it didn't really work for me as yet, though some people gave me a few tips a few weeks back that I haven't followed up on as yet.
>
> wxWidgets seems still to be going though and wxPython is rising as a phoenix . I haven't really used them though but maybe the latest version is worth a whirl.
>
> I guess people doing Qt stuff really do work with C++ if they don't work with Python? I'd call this an opportunity for D. The trick has to be to automate the creation of the binding. I have to admit I do not know what the technique is for PySide2 but PyQt certainly has a system for generation of the binding.
>
> Of course, Rust  https://github.com/rust-qt

As a company that will be hosted in the QT booth at SPS IPC Drives 2018 in Nuremberg at the end of November, C++ dominates.

We are calling a little D codebase from a QT application, but just to leverage some legacy old code.

I've used PySide, years ago, but nowadays the performance of the C++ compilers, and the agility of QT Creator are closing the bridge for a fast edit/compile/test cycle... the big advantage of PySide is the tremendous amount of python libraries that you can use in your application.

Said that, we are using QML, but I don't love it a lot...

- Paolo


October 20, 2018
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.
October 20, 2018
On Saturday, 20 October 2018 at 16:37:07 UTC, Atila Neves wrote:
> On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote:
>> [...]
>
> 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.
>
> [...]

There this pull request https://github.com/dlang/dmd/pull/8787
but apparently Manu is burn out from working on it.
October 20, 2018
On Saturday, 20 October 2018 at 22:19:48 UTC, 12345swordy wrote:
> On Saturday, 20 October 2018 at 16:37:07 UTC, Atila Neves wrote:
>> On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote:
>>> [...]
>>
>> 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.
>>
>> [...]
>
> There this pull request https://github.com/dlang/dmd/pull/8787
> but apparently Manu is burn out from working on it

I don't want to judge, but I need to point out that we have managed to make this discussion progress from outward-facing marketing to technical difficulties and related pull requests. This is not bad, but it is also a perfect example of how inward-facing the community can be and that is a part of what started this thread.
October 20, 2018
On 10/12/18 4:05 AM, Vijay Nayar wrote:
> But the D community has also been very receptive of changes to the language
> 

The community is. I don't feel like it's been true of the leadership for some years now (and I don't mean just W&A.)

> One thing that does concern me, is the avenues in which people can discover D.  For me personally, after a particularly nasty C++ project, I just googled for "alternatives to C++" and that's how I found D back in 2009 or so.  But the same search today turns up nothing about D.  I'm not sure sure how people are supposed to find D.

This is a VERY important thing, and it's true for many of us (myself included). This why it was a HUGE mistake when the community decided it should become taboo to promote D as a redesigned C++. That was ALWAYS D's core strength, we all know it, that's why many (if not most) of us are here, and hell, that's literally what D was *intentionally designed* to be.

But then political correctness came and threw that angle out the window, in favor of this awkward "fast code fast" nonsense, and we've been fighting the uphill "I don't understand the point of D" image battle ever since.
October 20, 2018
On 10/20/18 5:25 AM, 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. 

And KDE.

I've heard a lot of very good things about GtkD, and honestly, I have no doubts about any of it. Unfortunately though, the main problem with GtkD is simply GTK itself :(

> 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+?

I really hope so! No idea personally though :(

What about DWT? It seemed pretty good from what I could tell, though I still haven't ventured into D GUIs just yet myself. Are there issues people have with DWT? Or WxD?