Qt 3.1b1

[Simon Hausmann]

On Mon, Sep 09, 2002 at 10:30:03AM +0200, Reginald Stadlbauer wrote:
> > > > 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.

I actually think it's a likely scenario. I'm sure many developers
use standard packages from their xzy distro. They hear: Ah, a new Qt
is out, and it's binary compatible _and_ it offers those and that
new features. They'll download and compile it. But I'm not sure
they'll be happy about recompiling their kdelibs.

But I just realize that my point is void. All users upgrading to Qt 3.1
will have to recompile their kdelibs in any way, because the style
plugins need recompilation. And the same applies to developers using
kde widgets in the designer.

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

Ah, right, /me remembers Q_BUILDER in Torben's emoc hacks ;-)

Bummer.

Simon