On Thursday, 3 September 2015 at 15:15:47 UTC, motaito wrote:
Thanks for the details! I was afraid, of something like this.
To me D doesn't seam very competitive without a complete
toolset :( Given that D has been around for a while now I am
somewhat surprised it's not further along. I know it's a lot of
work and not easy to do but clearly there has been a need for
this for many years now. The resources I found were several
years old (not including that they must have been working on it
for a while before abandoning the project). It will be hard to
compete with something like QT.
I was hoping for a cross platform solution that would deliver
good performance without the complexity of c/c++. But if there
is no built in solution QT seams a better option. I wanted to
avoid QT because of the added complexity and the QT-windows
tend to lag on a windows platform. This may go away with
updates and bugfixes though.
With D's relatively easy ability to link C libs, gtkD is the way
I would've gone, IF I wasn't such a satisfied and long time user
of Qt across BeOS-OS/2-BSD-Windows-OSX-Android-iOS-embedded Linux
(did I miss any?). The monumental amount of continual work
involved in keeping a consistent professional interface blended
into the "major" operating systems and adjusted to make the
native user feel at home seems folly to attempt - though I do
keep my fingers crossed for dlangui for a gui lib done the "D"
way.
Anyway, though I have so enjoyed the huge part of Qt that is
non-gui, and especially their model/view components where I can
do all my model manipulation behind the scenes and practically
hot-swap or connect multiple views to a model.
I've spent much of the last year building commandline
applications with D running on the desktop and behind production
web applications on aws servers. And I've found a novel way to
relatively easily hook up thin Qt graphical interfaces on top of
the commandline app that interacts with JSON via stdin/stdout as
it does on servers. In the Qt graphical interface I put, for
example, a QTableView which I connect to a thin class that
inherits QAbstractTableModel and implements four methods, three
of which are 1 liners. The other method simply connects to stdin
and converts the JSON that it receives, from the D commandline
app, into data for each (row,column) that the View calls for. I
actually embed the D executable into the Qt application, then
extract and run it when the Qt app starts up. I'm always amazed
how un-noticably fast that is.
So, best of both worlds. The D implementation is generally
easier/more enjoyable for the actual guts of the tool, and I get
a perfectly slick Qt user interface.
sorry, this is already too long. I mean to open up and example
repo/wiki with that pattern. RSN (Real Soon Now)
good luck.
