QOb]ect must be first, so that limits Qt’s position here. VTK also likes to be first, so that’s a bit of a conflict. It appears that VTK’s approach is to have Qt-derived classes and vtkObject-derived classes and use them from each other. ParaView seems to do this too.
Generally speaking, the approach that most applications use, is to have QObject classes separate from vtkObject classes and have the QObject classes take ownership of vtk classes because the Qt provides the GUI application layer.
Why do you need it to be a QObject? Do you need Qt’s signals/slots, Qt’s RTTI, Qt’s dynamic property system and/or use Qt’s garbage collection in your class?
You don’t need to have a QObject to use slot/signal. We had a similar problem and we handled it by just subclassing from vtk, then explicitly handing the connect/disconnect ourselves and keeping track of the connection ourselves, for example:
_timerConn = QObject::connect(&_kbChecker, &QTimer::timeout, [this]() { // do something }});
When you are done with the connection, or on destruction, you just disconnect using the return value from connect.