View mode: basic / threaded / horizontal-split · Log in · Help
May 03
The Current Status of DQt
Hello everyone. From time to time, people ask in the newsgroup 
and also IRC about Qt bindings for D, so I thought it would be a 
good idea to give people an update on where my own bindings 
stand. First, if you want to take a look at my code as it stands, 
you can get it here.

https://github.com/w0rp/dqt

It depends on two other repositories which are also hosted on 
GitHub, and which are mentioned in the readme. Building dqt 
itself isn't that great, as I ran into some issues with DUB, but 
Sönke has since addressed my primary issue, so it may now be 
possible to build the project with the master branch version of 
DUB. Here is what I have done.

1. These bindings use SMOKE, which is a library which can be used 
to generate bindings for C++ libraries. The 'smokeqt' library 
does a Hell of a lot of work already for me. Everything I have is 
written in about 99% D. The "just SMOKE" part I have put in a 
separate repo, and it could potentially be used for wrapping 
other C++ libraries.
2. The majority of classes from Qt are generated as D classes 
which wrap around the C++ classes. This allows for polymorphism, 
at the expense of some additional resource management at times. 
(You can disable garbage collection and let Qt take over.)
3. Calling virtual method overrides from C++ isn't done yet, but 
I pretty much know how to do it, and there is some code in place 
which does about half of the job.
4. You can draw windows and so on with a DQt program. (I drew a 
gridlayout with a few buttons for a calculator successfully)

There are some important things left to do.

1. I have not accounted for multiple inheritance yet, which Qt 
uses. My idea was to nominate one class as the concrete class 
which is inherited (QObject) and then turn other classes into 
interaces which have seperate classes for implementation. 
(QPaintDevice)
2. I have not yet implemented signals and slots. Two options for 
this involve generating QMetaObject instances for classes, 
possibly via template mixins, which do what 'moc' does for C++. A 
second option is to use Qt5 for the library and to force all 
signals and slots behaviour to go through functions, as Qt5 can 
use function pointers as slots. (I prefer option 2.)

So, I am eager to hear what people think about all of this. Does 
anyone like the work that I have done, and will it be useful? 
Have I committed some terrible crime against nature, for which I 
must be punished? Does anyone have any ideas about things that 
could be improved, or where to go next? Please, let me know.

My progress has been somewhat slow in writing all of this, as I 
have been writing it mostly in the evenings, moslty during 
weekdays, after my day job. I've also been running into problems 
for which there are no easy answers, possibly no documentation 
for, and so on. So a great deal of my time has been spent more on 
thinking of what to do next, rather than writing anything. (It 
took me possibly months to come up with the resource management 
scheme that I have now.)
May 03
Re: The Current Status of DQt
On Sat, 03 May 2014 11:00:37 +0000
w0rp via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> So, I am eager to hear what people think about all of this. Does
> anyone like the work that I have done, and will it be useful?
> Have I committed some terrible crime against nature, for which I
> must be punished? Does anyone have any ideas about things that
> could be improved, or where to go next? Please, let me know.

I can't really comment much on your approach or implementation, because I
haven't looked at what you've done, and while I do have some experince with
Qt, I haven't done a lot with it (and I haven't done a lot with GUI
programming in general), so I'm not in a good position to comment on or
review a D wrapper for Qt.

That being said, if I were to write a GUI application in either C++ or D, I
would want to use Qt (preferably Qt5). And given what is on my todo list, I
expect that I'll be looking at writing a GUI application in D within a year
or two. So, having a useable wrapper library for Qt in D is something that
I'm very interested in seeing happen. I wasn't aware of your efforts in that
regard (I was just aware of QtD, though it's not clear to me how actively
developed it is at this point, since it was my understanding that the
original devs dropped it, but I know that some folks have repos of it with
more recent changes), but I'm very glad that someone is taking up this torch,
and I wish you the best of luck with it. I'm just not likely to be of much
help in reviewing or critiquing it at this point. However, there are quite
a few folks around here who are not only much more familiar with GUI
development but who are also very opinionated on the matter, so hopefully
some of them will be able to chime in with useful insights.

- Jonathan M Davis
May 03
Re: The Current Status of DQt
On Sat, 2014-05-03 at 11:00 +0000, w0rp via Digitalmars-d wrote:
[…]
> 2. I have not yet implemented signals and slots. Two options for 
> this involve generating QMetaObject instances for classes, 
> possibly via template mixins, which do what 'moc' does for C++. A 
> second option is to use Qt5 for the library and to force all 
> signals and slots behaviour to go through functions, as Qt5 can 
> use function pointers as slots. (I prefer option 2.)

It's Qt, signals and slots are necessary!

>From a personal perspective I only care about Qt5 and in particular QML.

> So, I am eager to hear what people think about all of this. Does 
> anyone like the work that I have done, and will it be useful? 
> Have I committed some terrible crime against nature, for which I 
> must be punished? Does anyone have any ideas about things that 
> could be improved, or where to go next? Please, let me know.

Whilst GtkD works and I am using it for a small GNOME-based project, Qt
is a better choice for systems that are to work on GNOME, OSX, KDE,
Android, and even Windows. QtD appears to have died, though Michael
Crompton has been trying to get it going again:
https://bitbucket.org/michaelc37/qtd-experimental

> My progress has been somewhat slow in writing all of this, as I 
> have been writing it mostly in the evenings, moslty during 
> weekdays, after my day job. I've also been running into problems 
> for which there are no easy answers, possibly no documentation 
> for, and so on. So a great deal of my time has been spent more on 
> thinking of what to do next, rather than writing anything. (It 
> took me possibly months to come up with the resource management 
> scheme that I have now.)

I suspect there is a "chicken and egg" situation here: D doesn't have a
strong Qt offering, so people do not use D for Qt work, and no-one is
using Qt and D so there is no resource to ensure a strong Qt offering
for D.

This cycle got broken for Go when Gustavo Niemeyer decided his group in
Canonical would use Go and QML and so he created the Go support for QML
on company time. He has focussed entirely on support for QML, and not
worried about providing a complete Go binding to Qt. Much of it is
there, but only with a view to supporting the QML aspects of things.
This has meant that Go+QML is really rather good.

I wonder if instead of trying to create a D binding to Qt, DQt (or QtD),
following Gustavo's approach with Go and just providing a D binding to
QML would get further faster.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 04
Re: The Current Status of DQt
I think Get experience from QML to create  a D binding to Qt, 
that is better than binding to QML. the Go's The programming 
thinking is not same to the C++,and D.

DQt is Working hard more, but has significant effect for D.

DQt is very clear.
May 04
Re: The Current Status of DQt
I'm intersting for DQt is better than QML.
May 04
Re: The Current Status of DQt
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?
May 04
Re: The Current Status of DQt
On 03/05/14 13:00, w0rp via Digitalmars-d wrote:
> Hello everyone. From time to time, people ask in the newsgroup and also IRC
> about Qt bindings for D, so I thought it would be a good idea to give people an
> update on where my own bindings stand. First, if you want to take a look at my
> code as it stands, you can get it here.
>
> https://github.com/w0rp/dqt

First of all, it's fantastic that you're working on this.  Many thanks!

I won't comment on the details of the code; it's outside my area of experience, 
but I do think that Qt support is something that will be very important for 
adoption of D.

> So, I am eager to hear what people think about all of this. Does anyone like the
> work that I have done, and will it be useful? Have I committed some terrible
> crime against nature, for which I must be punished? Does anyone have any ideas
> about things that could be improved, or where to go next? Please, let me know.

A remark about your README: it lists as dependencies "A recent Qt 4 version, 
like Qt 4.8".

I think you should be far more explicit, far earlier in the README, about 
exactly which Qt versions are supported.  Pretty much the first question I had 
on my mind, clicking on the link to your project, was, "Is this going to support 
Qt 5.x ... ?"

I also think that a focus on 4.x rather than 5.x is likely to be 
counter-productive.  5.2+ seems to be where all the interest is these days.

> My progress has been somewhat slow in writing all of this, as I have been
> writing it mostly in the evenings, moslty during weekdays, after my day job.
> I've also been running into problems for which there are no easy answers,
> possibly no documentation for, and so on. So a great deal of my time has been
> spent more on thinking of what to do next, rather than writing anything. (It
> took me possibly months to come up with the resource management scheme that I
> have now.)

I can sympathize with your predicament as I often find myself in the same 
position.  The good side is that the time spent thinking in this way is usually 
very productive when one comes to finally sit down and write :-)
May 04
Re: The Current Status of DQt
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.
May 04
Re: The Current Status of DQt
On Sunday, 4 May 2014 at 13:08:38 UTC, Joseph Rushton Wakeling via
> A remark about your README: it lists as dependencies "A recent 
> Qt 4 version, like Qt 4.8".
>
> I think you should be far more explicit, far earlier in the 
> README, about exactly which Qt versions are supported.  Pretty 
> much the first question I had on my mind, clicking on the link 
> to your project, was, "Is this going to support Qt 5.x ... ?"
>
> I also think that a focus on 4.x rather than 5.x is likely to 
> be counter-productive.  5.2+ seems to be where all the interest 
> is these days.

Qt 4.8 support comes largely from what is possible easily now. 
DQt uses SMOKE to wrap Qt. In particular smokeqt, which produces 
the SMOKE Qt bindings. You can get smokeqt for Qt 4 straight from 
most package managers (Arch Linux, Debian, Gentoo, ...) and it's 
also the current master version of the project on git. Someone 
has very recently been working on a Qt5 branch for smokeqt, so I 
expect Qt 5 support to come soon. Qt5 support for smokeqt will 
directly influcence Qt 5 support in DQt, and I might jump on it 
early for binding functions as slots. (A Qt 5 feature.)

Qt 4 support basically arises from what is easy to do right now. 
Supporting Qt 5 doesn't seem that far off. I went with Qt 4 for 
now because it's easier, and at this stage it's more important to 
work with something that can actually work and learn from that, 
than to try and work with something which might not actually work 
at all.
May 04
Re: The Current Status of DQt
On Sun, 2014-05-04 at 13:15 +0000, w0rp via Digitalmars-d wrote:
[…]
> 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 guess a dark corner is going to be GUI network applications (which I
have as one of my pet projects). Qt supports GUI and network on the same
event loop, which is both good and terrible. For PyQt5 with a single
thread (and a GIL) it is great. For languages such as D and C++ which
can manage multiple kernel threads on multicore machines I would think
separate even loops would be better (but I don't yet have any data, I am
just beginning to try this idea out – it is likely that many people have
already trodden this route…) For this latter case the D architecture I
have in mind is vibe.d for network and GtkD or QtD^H^H^HDQt for GUI. I
suspect to do this sensibly needs signals for Qt.
[…]
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home