Qt 3.1b1

[Reginald Stadlbauer]

On Monday 09 September 2002 09:57, Simon Hausmann wrote:
> 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.

This is only a problem if one updates to qt 3.1, does not recompile kdelibs 
but recompiles his/her own app with qt 3.1. Is this really a very likely 
scenario? If you only update the qt lib and link kdelibs + app agains it it 
is fine. If you recompile everything, of course there is no problem either.

> 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... :)

We thought about that too, but finding the constructors is harder than it 
seems. Either moc has to parse the whole public section of a class 
declaration to look for a standard-QObject constructor (which is out of moc's 
scope) or we have to introduce a macro which indicates a standard-QObject 
constructor. In the latter case this is a lot of manual work and so it is not 
much harder to write a factory class for all constructable objects (like we 
do with QWidgetFactory).

-- 
Reggie (reggie at trolltech.com)