Qt 3.1b1

Simon Hausmann hausmann at kde.org
Mon Sep 9 08:57:42 BST 2002

On Sun, Sep 08, 2002 at 01:39:02PM +0200, Matthias Ettrich wrote:
> On Saturday 07 September 2002 00:22, Dirk Mueller wrote:
> > On Fre, 06 Sep 2002, Marc Mutz wrote:
> > > Isn't Qt 3.1 supposed to be a drop-in replacement for Qt 3.0.x?
> >
> > Yes, I think so.
> >
> > > Because if you only update Qt, you'll get konq crashing and Kmail not
> > > opening a window, yet not quitting either. And strange debug output:
> >
> > There are some binary incompatibilites in the new moc code. 
> There are? Where?

There are no real binary incompatibilities in the moc code (except
three binary incompatibilities in Qt itself, which are already
reported though :)

But the fact that newly generated moc code references the new
qt_static_property symbol from the base class essentially means that
kdelibs has become binary incompatible for third-party developers as
soon as they upgrade Qt, because they can't continue to develop
their application without recompiling kdelibs (in order to get the
new symbols referenced by the moc code in their own app) . That's a
major headache IMHO.

But the qt_static_property stuff is very cool, or rather the fact
that meta objects are registered through static objects at load
time. How about adding a little factory functionality in the
generated moc code to instantiate the actual class? :-)

I could imagine that the problem though is to 'provide' all
constructors the class offers, and how to call them...

But the thought of

QObject *obj = QMetaObject::createClassInstance( "MyClass" );

is soooo attractive for script bindings... :)


More information about the kde-core-devel mailing list