> From: Olivier Goffart <[email protected]> > On Thursday 09 February 2012 10:42:07 Thiago Macieira wrote: >> On Thursday, 9 de February de 2012 10.07.16, Jedrzej Nowacki wrote: >> > Hi, >> > >> > Does anybody know why we have separation between QMetaTypeId and >> > >> > QMetaTypeId2 classes? >> >> Because the original QMetaTypeId that existed in Qt 4.0 lacked one > important >> feature, which Harald fixed in 4.2 or 4.3. >> >> Before harryF's changes, the Q_DECLARE_METATYPE macro did not save the > name, >> so you had to include the type's name in the registration function: >> >> qRegisterMetaType<MyType>("MyType"); >> >> This was necessary because the type's name cannot be easily gleaned > from the >> template parameter (I have a patch for that though, see >> https://codereview.qt- project.org/#change,670 ). > > It was before my time, but I think it is totallty unrelated to that, since > Q_DECLARE_METATYPE already registered the name in Qt 4.0 and that > QMetaTypeId2 > is only used for builtin types. > > I beleive it has been added so adding builting type do not conflicts with > Q_DECLARE_METATYPE of the same type. > > Indeed, in Qt 4.1, the list of supported metatype was quite small > http://doc.qt.nokia.com/4.1/qmetatype.html#Type-enum > But in Qt 4.2, where QMetaTypeId2 was added, that list has gained a lot of > types. > Without QMetaTypeId2, customer code that would have done > Q_DECLARE_METATYPE(QStringList) yould break
I think this should be handled such that it won't break such that: 1. It logs that it has already been registered, and preferably where the extraneous registrations are coming from. 2. Any extraneous registrations are dropped (not processed aside from #1). #1 is to help people track down registrations they don't need - or at least block them out so that they only occur with Qt versions that still need them (if they need the interoperability). > From: André Somers <[email protected]> >Op 9-2-2012 12:39, Stephen Kelly schreef: > >>> Can I merge QMetaTypeId and QMetaTypeId2? >> >>I always thought they were split so that Qt could add new built-in metatypes >>without breaking user code. >> >>Eg, if you merge them, any user code doing: >> >>Q_DECLARE_METATYPE(QModelIndex) >> >>will no longer compile until that line is removed (It is a built-in metatype >>now). >> >> > Not hindered by any knowledge of the internals of these classes: >Would it be possible to make such a statement a no-op then if the > type is already registered? > The effect should be a no-op with the possible addition of a log message (e.g. qDebug()) if it is already there so that people can track down the extraneous cases. That said, I'd like to see at least QAbstractSocket::SocketError registered as well. As it is, I typically have to register it before I can throw it through signals across thread boundaries. I'd suggest that any type - especially enums and standard types - that is in a signal/slot in the Qt API should be registered by Qt so that a signal can be used with it across thread boundaries. $0.02 Ben _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
