Qt support

[haxscramper]

I don't think it makes sense to try and provide an overly generalized solution that might be further extended in order to work with Qt. Instead, support should be built-in, especially considering this is a non-trivial thing to do even in this mode.

Without accounting for some basic interop problems, like extreme difficulty of inheritance #2 , wrapping methods #1 and other things that are most likely yet to be discovered, there are some Qt-specific problems, that make it harder to provide meaningful wrappers. Specifically - signal and slot mechanism, dynamic properties. Latter one is not as fundamental as slots, so it can be addressed sometimes later. Slots on the other hand are the most important feature, and I really need to consider how to approach them.

• Generating list of existing signals and slots.
  • Proof Of Concept: Re-implementing Qt moc using libclang provides an implementation of a tool that can read and analyze C++ source code while keeping track of the signal/slot mechanism. The problem with implementation - despite the article name, it uses libtooling API, which is quite hard to wrap, and will require a lot more stability than just Qt libtooling wrappers #19.
  • The alternative solution is to rely on boost::wave capabilities once again, in order to keep track of all macros that have been expanded. Considering Qt is split into lots of very clean headers (one per class), running tree-sitter&boost::wave pipeline would be a lot faster.
    • It is possible to fork and modify tree-sitter grammar for C++, to allow for signals/slots to be included in the access_specifier rule pattern.

Related

• Ideas for wrapping Qt?
• Qt GUI bindings nim-lang/needed-libraries#14
• https://forum.nim-lang.org/t/2586

[haxscramper]

After reading https://woboq.com/blog/verdigris-qt-without-moc.html I think it would be possible to use https://github.com/woboq/verdigris approach, either directly or via additional codegen. I would need to generate c++ classes at some point anyway, so it makes sense to extend on that approach. Although, generated header files could be processed my mic as well, but it would require separate build step after every class has been generated. Is it possible run nim compiler in steps? Generate cxx code, and then compile things separately.