[Development] QML, Widgets, and setParent

Simon Hausmann simon.hausmann at digia.com
Thu Dec 5 17:17:27 CET 2013

On Saturday 2. November 2013 11.25.07 Konrad Rosenbaum wrote:
> Hi,
> On Saturday 02 November 2013, Kevin Krammer wrote:
> > On Thursday, 2013-10-31, 20:17:43, Konrad Rosenbaum wrote:
> > > I've got it running
> > > for trivial QML files, however as soon as there are child widgets the
> > > running program aborts.
> > > 
> > > The abort is caused by QObject::setParent, which contains this little
> > > gem: Q_ASSERT(!d->isWidget);
> > 
> > Hmm. The same code is in Qt4. I think it "works for me/us" because we are
> > building against our distribution's Qt packages which are release builds
> > and thus doesn't have the Q_ASSERT.
> No, it works for you because the Qt4 QML code (qqmlvme.cpp) contains special
> code to handle Widgets - in Qt5 it was deactivated to remove the dependency
> on the QtWidget module.
> The code of QObject::setParent itself is absolutely identical (I didn't
> check all the lines of QObjectPrivate::setParent_helper though). Qt4
> contains the same Q_ASSERT.
> > > I kind of ran out of ideas on how to solve this. Should I consider
> > > setParent, qqmlvme or the direct use of QWidgets as a bug?
> > 
> > I agree with Alan on setParent() being in error, the problem is some
> > other areas rely on that. E.g. QWidget::parentWidget() does a
> > static_cast of parent() to QWidget*
> Upon reading the code of QWidget a bit more I must conclude that this was
> done deliberately (both in Qt4 and Qt5). If widgets are supposed to be able
> to have non-widget parents, then this is one hell of a design bug that can't
> be easily fixed inside a single minor release.
> I'm coming to the conclusion that I have only three options:
> 1) give up - I must say, I don't like this one ;-)
> 2) do a work-around by giving all widget classes a QObject based wrapper in
> the framework: on the plus side this would need no changes to Qt, on the
> down side this would make it slower and use up significantly more memory
> 3) fix qqmlvme.cpp somehow: the trickiest one, since reintroducing a
> dependency on QtWidgets is not an option; the solution would probably
> involve a plugin that is loaded if/when a widget is encountered there

Just for reference on this mailing list, I propose the following fix for (3) 
that should restore the behavior of Qt 4:



More information about the Development mailing list