Port to miqt-style bindings

[arnetheduck]

arnetheduck#1 replaces DOtherSide with a PoC of automatically generated C++ -> C bindings based on the miqt - opening this issue to explore whether this would be an interesting way forward for nimqml, with a view to reduce / share qt wrapper maintenance in the nim/qt community.

jerous86/nimqt#54 similarly explores this option for the non-qml part of qt, with which the C bindings could also be shared.

[filcuc]

To be honest the real problem with Qt is binding the QAIM classes and I doubt any automatic mechanism…I’ve been burned too many times with Qt classes. The NimQML and dotherside projects didn’t want to be a Qt wrapper. They wanted only to exposes the minimal set of API for doing the UI parts. For the rest the std library of the used language should be used (or 3rdParty libraries)

[arnetheduck]

Qt is binding the QAIM classes and I doubt any automatic mechanism

I've managed some progress on this front as well - in fact, the PR linked above now can run all the examples from nimqml (like contactapp etc) using the automatically generated qt bindings - QAIM included.

The thing that makes it work is that the code dynamically generates both a metaobject and the metacall infrastructure from the nim object declaration in a way that is binary-compatible with what Qt normally does - one thing that helps here is that with all of qt available, the C code no longer has to convert everything to QVariant - instead, it can work with void** which removes a large part of what DOtherSide was doing (shuffling things into QVariant). Check out the implementation of dos_metaobject_create which like the rest is now pure nim: https://github.com/arnetheduck/nimqml-miqt-poc/pull/1/files#diff-7f8cf6a029f39b4f5a3072e98374fd30cb73691443de443ad41ca705b82824fdR557

For signal/slot bindings in general, there are two tricks:

• for signals in existing classes, it uses a simple functor binding but it manages memory by adding a destructor - this removes the need for "table-based" memory management
• for custom signal bindings, there's a custom slot binding implementation that does the same, but in a slightly different way - in particular, the native language is responsible for unpacking void** into native types.

For overriding virtual functions, the nim code provides a VTable - this is again where memory and callback management happens, meaning that there is very little going on in the automatically generated code.

[filcuc]

From what i see basically you're replacing the DOtherSide with MIQT...so what's the point? i mean both MIQt and DOtherSide are C wrappers over Qt...

[arnetheduck]

so what's the point

the point is to have access to all qt classes (networking, various web views, clipboards, tray icons etc - there are hundreds if not thousands of these) and to have these automatically generated so that they're complete with respect to C++ - nimqml exposes only a small fraction of what qt has available, even for the types that it actually exposes (ie qvariant can hold all "known" qt types that get used in custom widgets while nimqml is limited to 10:ish and can't express custom-registered qmetatype instances / constructors etc) - basically a single qt binding combining nimqml and nimqt that is easy to keep up to date.

[arnetheduck]

I think the way to look at it is that the poc proves that you can build a project like nimqml over an automatically generated binding like miqt - the binding has better integration with metatype and doesn't have to convert to/from qvariant because of its completeness, ie performance is better and there's less "binding" magic involved.

Anyway, I think we can close this issue if this is not at all of interest.