Does or should qmlRegisterUncreatableType and qRegisterMetaType need to go in main.cpp and be executed after QGuiApplication app? Or is considered best practice, etc.?
It does not need to be in main.cpp. It does need to be executed after QGuiApplication.
What you wrote is how most people do it. Is it best practice? Well, for big projects I'd say it's good to move that stuff to some other header, just to keep main.cpp cleaner. But it does not matter much, it's only styling "issue". You won't gain or loose performance here.
console.log( "Ddddd: ", Support.Ddddd ); works, but I lose the explicit connection to the ETestB datatype. I would prefer to be able to write Support.ETestB.Ddddd or something. Is that possible now or something that might be implemented in a future version?
I don't think it's supported and I have not heard of plans to support it. Maybe it will come, though, who knows.
If I remove qRegisterMetaType, current behavior remains the same. I am not sure what, exactly, qRegisterMetaType is doing for me here. Can someone provide some insight...?
Q_ENUM has already registered it with meta object system. You don't need to do it manually.
Let's say that I add:
enum class ETestC
Q_ENUM( ETestC );
to the Support class. And qRegisterMetaType<Support::ETestC>( "Support.ETestC" ); to the main function. There is now a namespace collision between ETestC and ETestB. According to some documentation, it seems like I should add Q_CLASSINFO( "RegisterEnumClassesUnscoped", "false" ) to the Support class. However, when I do all of that, I see:
If you are determined to keep the signal class and the slot class separate without sharing a common enum, but you are prepared to do things via a common "controller" class, you can proceed as follows:
Export the two enums from their .h files.
Import these two files into the "controller" class.
Have the controller class place the connect() from the signal class to the slot class.
The call to the connect() attaches the signal with its enum to a lambda (or similar) in the controller which maps/translates the signal's enum value to the corresponding slot's enum value.
My issue with that solution is that you're getting the information at runtime, instead of at compile time. There is increased chance of errors and there isn't really a need to inquire the meta object system in this case.
Let me tone down this discussion by saying that the original reason for my question has disappeared. I misunderstood how QPrinter worked. I thought I would need the string versions of the QPrintDialog enums to pass on to lp. Turns out QPrinter does what I need to do automatically and I don't need to call lp. Thanks for the lively discussion though.