男人手大代表什么

20 December 2012

QEventLoopLocker

One of the early complete new features contributed by KDAB to Qt 5 was the QEventLoopLocker. This is a class whose need first appeared in KDE, and it relates to the quitOnLastWindowClosed concept in Qt. For KDE applications, there was a desire to quit applications when the last window was closed, but there was also a need to finish some operation before quitting the application. For example, the email with the large attachment is not fully sent yet, or we're still uploading a large file to an FTP site somewhere. As these operations typically have separate, out-of-process UI, it is ok to not show any window until the job is finished.

That concept was generalized to be able to quit not just the application, but any event loop or any thread, using the new QEventLoopLocker RAII class. This will make implementation of job-queues much easier in Qt 5. For maintenance, the quitOnLastWindowClosed feature in Qt is implemented using the same implementation details as the QEventLoopLocker.

Improved MetaType features

The QMetaType system has seen some large improvements in Qt 5 contributed by KDAB. Some of the improvements were explained at Qt Developer Days in Berlin.

Declaring and using metatypes is now much more convenient in many cases. For example, if you wrote a MyObject type inheriting QObject, or MyWidget type inheriting QWidget in Qt 4, and you wished to put an instance of it into a QVariant, you would need to first use

Q_DECLARE_METATYPE(MyObject*)

姜黄与生姜有什么区别	维生素k2是什么	晚上2点是什么时辰	石女是什么	激光脱毛对人体有没有什么危害
三月三日是什么星座	烦恼是什么意思	肚脐右边疼是什么原因	常委是什么级别	胸闷想吐是什么原因
为什么白醋把纹身洗掉了	吉祥物是什么生肖	肩膀疼吃什么药	无机磷偏低有什么影响	damon英文名什么寓意
长期便秘是什么原因	不老实是什么意思	太多的借口太多的理由是什么歌	长裙配什么鞋子好看	五十肩是什么意思

桃子又什么又什么hcv8jop9ns3r.cn	自然周是什么意思hcv8jop7ns6r.cn	肝不好看什么科xinjiangjialails.com	都有什么大学hcv8jop5ns9r.cn	吃土豆有什么好处和坏处hcv8jop2ns9r.cn
二月二十一是什么星座hcv9jop5ns5r.cn	大便遇水就散什么原因hcv9jop2ns6r.cn	黄瓜不能和什么一起吃xscnpatent.com	肋骨里面是什么器官hcv8jop0ns6r.cn	煲电话粥什么意思hcv8jop8ns8r.cn
脑梗吃什么食物chuanglingweilai.com	吃什么增强抵抗力和免疫力cl108k.com	类风湿吃什么药最有效hcv7jop5ns5r.cn	窒息是什么意思hcv8jop5ns2r.cn	太白金星是什么神hcv8jop6ns1r.cn
异型增生是什么意思啊onlinewuye.com	眼屎多用什么眼药水好hcv9jop5ns8r.cn	7月24日是什么日子hcv9jop2ns2r.cn	梦见捡手机是什么意思hcv9jop7ns0r.cn	12月14号是什么星座1949doufunao.com

somewhere in your code. That would allow you to use

QVariant var = QVariant::fromValue(myObjectInstance);

In Qt 5, the Q_DECLARE_METATYPE use is no longer needed if your type inherits directly or indirectly from QObject. It is also not needed for any Qt container or smart pointer using types which are themselves metatypes.

For example, these constructs are no longer needed when using Qt 5:

Q_DECLARE_METATYPE(QList<int>)
?Q_DECLARE_METATYPE(QList<QObject*>)
?// Because MyObject* is automatically a metatype from above!
 Q_DECLARE_METATYPE(QList<MyObject*>)
 Q_DECLARE_METATYPE(QSharedPointer<<MyObject*>>)
 // Because QList<MyObject*> is automatically a metatype from above!
?Q_DECLARE_METATYPE(QVector<QList<MyObject*>>)

This is also true for types where the user does still have to use Q_DECLARE_METATYPE, for example, when the type does not inherit from QObject:

struct SomeStruct {};
 Q_DECLARE_METATYPE(SomeStruct)
 // No need for Q_DECLARE_METATYPE(QList<SomeStruct>)

 // later:
 QList<SomeStruct> structs;
 QVariant var = QVariant::fromValue(structs);

In some cases in Qt 4, it is also necessary to use the qRegisterMetaType method. The reason to need this is usually that Q_PROPERTY is used with a metatype which is not built-in (types such as int and QString are built-in and don't need to be marked as metatypes).

With the new possibility of automatically declaring certain types as metatypes, the question of whether we could automatically register them came up too. Because qRegisterMetaType only needs to be used in a small number of cases, most of which relate to QObject or Q_PROPERTY in some way, it was possible to use moc to automatically register types which have not yet been registered. So now, in Qt 5, there are even fewer reasons to have to use qRegisterMetaType.

Another new qRegisterMetaType related feature in Qt 5 is the detection of accidental ODR violations. This often does not have any effect, but can accidentally hide problems such as typos which can mysteriously make your application not work properly. Now, you will get a compile-time or runtime error if using Q_DECLARE_METATYPE and qRegisterMetaType together in a way which has undefined behavior.

Another new feature is the possibility for built-in qobject_cast-style conversion through the inherited types. For example:

MyObject *myObjectInstance = ...;
 QVariant var = QVariant::fromValue(myObjectInstance);

 // elsewhere...
 if (var.canConvert())
 {
   QObject *obj = var.value();
   // Use the properties of obj
 }

This adds features 'for free' to domain-specific languages implemented using Qt where the language is based on QObject and properties. It only works for types which inherit from QObject, and can not be generalized for a generic static_cast. The reason for that limitation is that internally it uses the generated QMetaObject of the stored type. Future versions of Qt will extend this feature in a similar way for QSharedPointer conversions.

Another nice but minor feature is that pointers to QObject derived types contained in a QVariant now print out their address and objectName when used with qDebug. For example:

QLabel* l = new QLabel;
 l.setObjectName("someLabel");
 QVariant var = QVariant::fromValue(l);
 qDebug() << var;
 // Qt 4 prints: QVariant(QLabel*, )
 // Qt 5 prints: QVariant(QLabel*, QLabel(0x7fff792fefa0, name = "someLabel") ))

The goals I wrote about elsewhere last year are now met, though the implementation is somewhat different in Qt 5. The SFINAE pattern I wrote about is used extensively to make these features possible.

CMake Config files

For many users of Qt, the CMake buildsystem tool provides advantages over the bundled qmake. Some of the differences compared to qmake were part of a presentation at the recent Qt Developer Days hosted by KDAB in Berlin. Part of the difference in how using CMake will differ when using it with Qt 4 versus Qt 5 is that 'CMake Config files' are now generated as part of the build-process of Qt itself and shipped in packages. I previously detailed what that means for users of CMake, and have added new comprehensive documentation to guide new users through the process of using CMake with Qt 5.

Although porting is required when changing from using Qt 4 to Qt 5, simple variable mappings can ease the porting burden.

Tags:

14 Comments

Very nice! QEventLoopLocker sounds especially appealing. I always thought Amaroks "I'm going to keep running in systray unless you explicitly tell me otherwise" was a pretty neat workaround, but QEventLoopLocker sounds like a more purposeful solution.

Wow great work :) Thanks for KDABs involvement :)

Nice to see so many under the hood improvements also in those core areas :)

These are really great improvements in Qt meta-object features :) Some of them have already made things easier in my daily work. Do I still need to use Q_DECLARE_METATYPE(QList*) ? Supposing QList doesn't inherit from QObject, I gues the answer is yes, right ? :)

Extracting QObject's from QVariant's created from QObject-derived classes is awesome ! Any chance for having this also working to extract a QList from QVariant's containing QList ? Those weird reinterpret_cast's always scare me :)

Oops, some characteres have been removed. I mean: Do I still need to use Q_DECLARE_METATYPE(QList < QObject * > *) ?

And any chance for extracting a QList < QObject * > from a QVariant build from a QList < MyObjectDerived * > ?

Hi there,

Yes, you still need to use Q_DECLARE_METATYPE(QList < QObject * > *)

Having a pointer to a QList is not really common enough to have explicit code for :).

I hope to make it easier to handle QList < MyObjectDerived* > but it didn't make it into Qt 5.0. We'll see what is possible for 5.1, but no guarantees I'm afraid, due to backwards compatibility.

Thanks ! Those new features already do a great job :)

Hi again,

Maybe I misunderstood what you said about qRegisterMetaType, but when using QMetaProperty::read on a property with type QObjectDerived * or QList/QSet of QObjectDerived *, I get a run-time message:

Unable to handle unregistered datatype 'QList' for property 'Teste::User::myClassList'

Do I need to run qRegisterMetaType for those cases ? I've noticed that QVariant::fromValue implictly run a qRegisterMetatype.

Thanks,

I've just tried it, and it works for me.

Maybe try sending a minimal code example by email.

Hi, I've just sent you an example of that.

Thanks,

Thanks.

The problem is that when moc is run on user.h, MyClass is only forward declared, so moc does not know it is a QObject subclass. That's a limitation of the implementation.

Sorry about that.

No problem, that's a good reason to use a full #include instead of forward decl.

Thanks for help :)

Hi there again,

I'm facing the unfortunate case of having two classes with the same name in different namespaces:

namespace QtUml {
    class QClass ...
        Q_PROPERTY(p1 ...)
        ...
        Q_PROPERTY(pn ...)
}
namespace QtMof {
    class QClass ...
        Q_PROPERTY(p1 ...)
        ...
        Q_PROPERTY(pm ...)
}

n > m

I have no explicit Q_DECLARE_METATYPE in my code, but it seems moc auto declares both as 'QClass *'. Both classes are loaded as plugins (QtMof::QClass is loaded after QtUml::QClass). I'm using qDeclareMetaType and qDeclareMetaType.

For some reason, when both plugins are loaded, the metaObject class from QtUml::QClass shows only those properties declared in QtMof::QClass (apparently because moc is also declaring it as QClass * and therefore overriding previous QClass * declaration for QtUml::QClass *).

Any hint for that issue ? Any way to tell moc to not auto-declare pointers to QObject-inheriting classes ?