I got a bit of a mind freeze reading that sentence since my first thought was “why would someone deliberately give up on Qt’s reflection system” but only then realized they’re still using QMetaObject (the thing that actually enables reflection and signals and slots), just building it with something else.
Yes, exactly. So a standard compiler can be used, making language bindings much cleaner, while the runtime functionality and library compatibility are preserved.
And then there’s DQt, which uses DLang’s compile-time function execution instead of the meta-object compiler.
@herzenschein
If you are interested in Qt without the MOC I can also recommend @copperspice_cpp that is a fork of Qt4 but relies heavily on#modernCpp @ono@kde
@ami@herzenschein@ono@kde, CopperSpice started as derivative work build includes everything up to Qt 5.6. Our team has redesigned major sections of the code base to provide real utf-8 strings, standardized containers, reduce UB, improved pointers, etc.
It’s an interesting project, but as a fork, I would be concerned about its compatibility with standard Qt & KDE libraries, widgets, and styles. Can you comment on that?
@ono, Thanks for your question. One of our main goals was to maintain compatibility with Qt user code. We have worked with a significant number of projects who migrated to CS and no one lost functionality. Most code will work without any modifications.
We have a parser (PepperMill) which you run one time to convert anything in your header files which used moc. For example, we change Q_OBJECT to CS_OBJECT(class_name).
I think you’re talking about migration from Qt to CopperSpipce, though, yes? I’m talking about integration with existing desktop environments. Making use of the themes that are already installed. Communicating with existing libraries via the existing interfaces. Are there any hitches to be aware of on that front?
And language bindings, for those of us who are trying to get away from writing in C++?
@ono, In terms of using an existing library, if it is a C++ library this works great. If the library was written using Qt it will need to be migrated to CopperSpice. This has already been done for a few libraries.
Our CS team has experience with library migration and we are available to help with this process.
Unfortunately, that leaves out the kind of integration I was asking about (and the kind implied in this post), through existing Qt & KDE shared libraries and such.
CopperSpice might still be interesting for stand-alone projects written in C++, though, and I appreciate that you’re here engaging with the community.
@herzenschein@ono, Removing moc did not require losing the reflection or introspection. In fact we were able to add more compile checks. Moving to CMake was a breeze since we had no code generator dependencies.
I got a bit of a mind freeze reading that sentence since my first thought was “why would someone deliberately give up on Qt’s reflection system” but only then realized they’re still using QMetaObject (the thing that actually enables reflection and signals and slots), just building it with something else.
Yes, exactly. So a standard compiler can be used, making language bindings much cleaner, while the runtime functionality and library compatibility are preserved.
And then there’s DQt, which uses DLang’s compile-time function execution instead of the meta-object compiler.
@herzenschein
If you are interested in Qt without the MOC I can also recommend @copperspice_cpp that is a fork of Qt4 but relies heavily on#modernCpp
@ono @kde
@ami @herzenschein @ono @kde, CopperSpice started as derivative work build includes everything up to Qt 5.6. Our team has redesigned major sections of the code base to provide real utf-8 strings, standardized containers, reduce UB, improved pointers, etc.
It’s an interesting project, but as a fork, I would be concerned about its compatibility with standard Qt & KDE libraries, widgets, and styles. Can you comment on that?
Also, what language bindings does it offer?
@ono, Thanks for your question. One of our main goals was to maintain compatibility with Qt user code. We have worked with a significant number of projects who migrated to CS and no one lost functionality. Most code will work without any modifications.
We have a parser (PepperMill) which you run one time to convert anything in your header files which used moc. For example, we change Q_OBJECT to CS_OBJECT(class_name).
Here is a link to the macros which are modified.
https://www.copperspice.com/docs/cs_overview/m_macros_metaobj.html
I think you’re talking about migration from Qt to CopperSpipce, though, yes? I’m talking about integration with existing desktop environments. Making use of the themes that are already installed. Communicating with existing libraries via the existing interfaces. Are there any hitches to be aware of on that front?
And language bindings, for those of us who are trying to get away from writing in C++?
@ono, In terms of using an existing library, if it is a C++ library this works great. If the library was written using Qt it will need to be migrated to CopperSpice. This has already been done for a few libraries.
Our CS team has experience with library migration and we are available to help with this process.
That’s as I expected; Thanks for confirming.
Unfortunately, that leaves out the kind of integration I was asking about (and the kind implied in this post), through existing Qt & KDE shared libraries and such.
CopperSpice might still be interesting for stand-alone projects written in C++, though, and I appreciate that you’re here engaging with the community.
@herzenschein @ono, Removing moc did not require losing the reflection or introspection. In fact we were able to add more compile checks. Moving to CMake was a breeze since we had no code generator dependencies.