I'm using QT's QQuickFramebufferObject
class which inherits from QQuickItem
in Qt library.
I have the following user-defined class:
class OpenGlBufferItem: public QQuickFramebufferObject
And I need my OpenGlBufferItem
class to also derive from ReactItem
. The problem is that ReactItem
ultimately derives from QQuickItem
too:
class ReactItem : public QQuickPaintedItem
because QQuickPaintedItem
inherits from QQuickItem
So we have the following problem:
QQuickItem
/ \
/ \
QQuickPaintedItem QQuickFramebufferObject
/ \
ReactItem OpenGlBufferItem
What I need is
QQuickItem
/ \
/ \
QQuickPaintedItem QQuickFramebufferObject
/ \
ReactItem /
\ /
\ /
OpenGlBufferItem
Normally, to solve diamond problems we'd simply declare some classes as virtually inheriting from others. However, I cannot declare the classes RectItem
, QQuickPaintedItem
, QQuickFrameBufferObject
, because they are already given.
How should I proceed?
UPDATE:
If I simply tryo to do
class OpenGlBufferItem: public QQuickFramebufferObject, public ReactItem
I get these kind of errors:
Command failed: ./build.sh -e "modules/mediaplayer/desktop"
In file included from /home/lz/orwell/orwellJS/desktop/modules/mediaplayer/desktop/orwell_subdir/orwell_autogen/EWIEGA46WW/moc_OpenGlBufferQtQuick.cpp:9:0,
from /home/lz/orwell/orwellJS/desktop/modules/mediaplayer/desktop/orwell_subdir/orwell_autogen/mocs_compilation.cpp:2:
/home/lz/orwell/orwellJS/desktop/modules/mediaplayer/desktop/orwell_subdir/orwell_autogen/EWIEGA46WW/../../../../../../../../OpenGlBufferQtQuick.h: In constructor ‘OpenGlBufferItem::OpenGlBufferItem(QQuickItem*)’:
/home/lz/orwell/orwellJS/desktop/modules/mediaplayer/desktop/orwell_subdir/orwell_autogen/EWIEGA46WW/../../../../../../../../OpenGlBufferQtQuick.h:90:13: error: reference to ‘connect’ is ambiguous
connect(parent, SIGNAL(widthChanged()), this, SLOT(parentWidthChanged()));
^~~~~~~
In file included from /home/lz/Qt5.11.2/5.11.2/gcc_64/include/QtCore/QObject:1:0,
from /home/lz/orwell/orwellJS/desktop/modules/mediaplayer/desktop/orwell_subdir/orwell_autogen/EWIEGA46WW/../../../../../../../../OpenGlBufferQtQuick.h:3,
from /home/lz/orwell/orwellJS/desktop/modules/mediaplayer/desktop/orwell_subdir/orwell_autogen/EWIEGA46WW/moc_OpenGlBufferQtQuick.cpp:9,
from /home/lz/orwell/orwellJS/desktop/modules/mediaplayer/desktop/orwell_subdir/orwell_autogen/mocs_compilation.cpp:2:
/home/lz/Qt5.11.2/5.11.2/gcc_64/include/QtCore/qobject.h:308:13: note: candidates are: template<class Func1, class Func2> static typename std::enable_if<(QtPrivate::FunctionPointer<Func2>::ArgumentCount == -1), QMetaObject::Connection>::type QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const QObject*, Func2, Qt::ConnectionType)
connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, const QObject *context, Func2 slot,
^~~~~~~
/home/lz/Qt5.11.2/5.11.2/gcc_64/include/QtCore/qobject.h:300:13: note: template<class Func1, class Func2> static typename std::enable_if<(QtPrivate::FunctionPointer<Func2>::ArgumentCount == -1), QMetaObject::Connection>::type QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, Func2)
connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, Func2 slot)
^~~~~~~
/home/lz/Qt5.11.2/5.11.2/gcc_64/include/QtCore/qobject.h:269:13: note: template<class Func1, class Func2> static typename std::enable_if<(((int)(QtPrivate::FunctionPointer<Func2>::ArgumentCount) >= 0) && (! QtPrivate::FunctionPointer<Func2>::IsPointerToMemberFunction)), QMetaObject::Connection>::type QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const QObject*, Func2, Qt::ConnectionType)
connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, const QObject *context, Func2 slot,
^~~~~~~
/
and a lot more
This is not possible.
I was thinking about using the CRTP (Curiously Recurring Template Pattern), which could theorhetically be employed if you can modify one of the classes and can handle its restrictions. But it will not work in your case as ReactItem is not deriving directly from QQuickItem, but from QQuickPaintedItem.
Let's assume that was not the case:
ReactItem would need to be changed to look like this:
The class hiearchy would look like this:
The restrictions of this approach is, that the two ReactItem instantiations are unrelated types with regards to the type hierarchy. This means a lot of the code previously referring to
ReactItem
might needs to be changed.This is quite easy to do for functions:
It is a lot trickier for templated data members like
std::vector<ReactItem*>
.