Can you explain in more detail some points that are difficult for me:

widgets/label.d file. I see a C++ mapping of class QLabelPrivate to structure D
extern(C++, class) struct QLabelPrivate;
this makes sense.

I see below an implementation of a class D named QLabel
class /+ Q_WIDGETS_EXPORT +/ QLabel : QFrame
in which I see calls to methods of the QLabel class.

I don't understand at what stage (where exactly) the mapping
QLabelPrivate structure methods onto QLabel methods.

I expected to see something like:
QLabelPrivate dd = QLabelPrivate(...);
and then
dd.MetodsQLabel(...)

Can you explain this place in more detail.

On Tuesday, 7 December 2021 at 06:33:18 UTC, MGW wrote:
> Can you explain in more detail some points that are difficult for me:
>
> widgets/label.d file. I see a C++ mapping of class QLabelPrivate to structure D
> extern(C++, class) struct QLabelPrivate;
> this makes sense.
>
> I see below an implementation of a class D named QLabel
> class /+ Q_WIDGETS_EXPORT +/ QLabel : QFrame
> in which I see calls to methods of the QLabel class.
>
> I don't understand at what stage (where exactly) the mapping
> QLabelPrivate structure methods onto QLabel methods.
>
> I expected to see something like:
> QLabelPrivate dd = QLabelPrivate(...);
> and then
> dd.MetodsQLabel(...)
>
> Can you explain this place in more detail.

QLabel is also extern(C++), because the top of the file has "extern(C++):". Most methods in QLabel are directly implemented in the Qt library. Some are also implemented in D. For example QLabel.setText has a wrapper accepting the text without ref, so it can be called without creating a temporary variable.

QLabelPrivate is used internally by Qt. This declaration is actually unused in the bindings. Many Qt types have a pointer to private data. New versions of Qt can then change the private data without changing the ABI between Qt libraries and applications. The constructor of QLabel creates an instance of QLabelPrivate and passes it to the constructor of the parent class (https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qlabel.cpp.html#213). QObject stores it then as d_ptr.

On Sunday, 5 December 2021 at 12:54:21 UTC, Tim wrote:
> DQt contains new experimental bindings for using a subset of Qt with D.
> Qt is a library for writing cross-platform graphical user interfaces.
> Currently bindings exist for the Qt modules core, gui and widgets. The
> bindings use extern(C++) and don't need any wrapper in C++. They are
> based on Qt 5.15.2 and tested on Linux and Windows, but need a dmd
> compiled from master for Windows.
>
> For more details see the README.md in the repository:
> https://github.com/tim-dlang/dqt
>
> It is also available with dub:
> https://code.dlang.org/packages/dqt

Wow, this looks really cool! I have actually been holding back from learning D simply because it is hard to bring Qt with me. I did get dqml and DOtherSide set up yesterday, so I'm working my way through the D docs now, but this looks like it has potential to be more than just a wrapper around loading QML and interfacing D classes to QML.

Here's hoping you are successful in getting DQt to extend to cover all of Qt instead of just a few modules! :) If I felt like I had enough D knowledge, I might try lending a hand, but I am unfortunately not there yet :(

On Monday, 6 December 2021 at 16:14:03 UTC, Tim wrote:
> I wrote a converter, but also had to make many manual changes.

Can we see the converter source? I'd be interesting in both looking at the code and also seeing if I can modify it to work with another library (i.e. Wt).

On Friday, 10 December 2021 at 02:35:12 UTC, LorenDB wrote:
> Can we see the converter source? I'd be interesting in both looking at the code and also seeing if I can modify it to work with another library (i.e. Wt).

I have not released the converter yet. It is currently not very user friendly and needs many manual changes to the result, which I want to improve. It also has Qt specific parts. Qt does not use many types from the C++ STL or new C++ features in the API. This makes the bindings for Qt a bit easier, because only types from Qt are necessary.

On Friday, 10 December 2021 at 17:38:56 UTC, Tim wrote:
> I have not released the converter yet. It is currently not very user friendly and needs many manual changes to the result, which I want to improve. It also has Qt specific parts.

I will definitely be watching for the release of the converter code! Today I read through the D tour, so I now feel like I have a fairly good grasp of the language and am ready to start doing things with D instead of with C++, which means that I am doubly excited about getting DQt to work with all of Qt.

> Qt does not use many types from the C++ STL or new C++ features in the API. This makes the bindings for Qt a bit easier, because only types from Qt are necessary.

Maybe Qt 5 doesn't use lots of new C++ features, but Qt 6 may be harder to generate bindings for since it requires C++17 instead of C++98.

Anyway, if you ever want some extra help with this project, I'd be glad to lend a hand!

On Saturday, 11 December 2021 at 00:47:56 UTC, LorenDB wrote:
> On Friday, 10 December 2021 at 17:38:56 UTC, Tim wrote:
>> I have not released the converter yet. It is currently not very user friendly and needs many manual changes to the result, which I want to improve. It also has Qt specific parts.
>
> I will definitely be watching for the release of the converter code!

For generic C++ code you can try my generator (yes it does code conversion, not just signatures), it handles like 80% of the job, the rest 20% is manual fixing signatures and code here and there, however newer C++ features is not yet covered.

https://github.com/Superbelko/ohmygentool