Ok, so I guess what you are saying is that if I stick to the RC1 tar ball instead of checking Qt out from "main trunk" (dunno if this is the correct git phrasing), I shouldn't see these kind of problems?
Btw. have anyone thought of mapping the open source map program Marble to Jambi? I tested the generator on the MarbleMap class and got some stubs generated, but haven't tried compiling anything yet. Regards, Helge Fredriksen > Hi, Helge. > > Yes, this is what the reject-enum-value tag is for: > > > http://doc.trolltech.com/qtjambi-4.5.2_01/com/trolltech/qt/qtjambi-typesystem.html#reject-enum-value > > > However, mapping Qt 4.7 when Qt 4.6 is not even out yet, is not such a > good idea, I think, since enums such as this are likely to get a > distinct ordinal at some point before Qt 4.7's release (the ordinal > increases when changes are made to QDataStream which are not backwards > compatible.) So if you reject it now and then forget to put it back, > you'll lose API later on. Also, since the API will fluxuate until it > freezes, you will also end up having redundant entries in the type > system, e.g. for classes that are added to Qt and then removed again > later on for some reason. To minimize this, we usually try to wait > until the Qt API stabilizes before we start mapping it. > > If you do want to map Qt 4.7 now, though, reject-enum-value is the way > to go. In general, if one of the enum values in question were in an > earlier version of Qt Jambi, identify which and reject all the others. > I'd suggest making a separate repository for this, since the changes > to the type system may not play well with Qt 4.6. > > -- Eskil > > > > _______________________________________________ Qt-jambi-interest mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
