25

I am not able to understand the usage of Q_PROPERTY. How th Q_PROPERTY helps in making a program defensive? What is it used for? I have seen the forum, but really not able to make its applicaton. I have understood the example, but not it's usage.

Here is the example, what do I gain with it. I understand that read will give a privilege of reading only.

The write property will give the privilege to write only. But what is the need of it? Can someone exemplify it?

 class MyClass : public QObject
 {
     Q_OBJECT
     Q_PROPERTY(Priority priority READ priority WRITE setPriority NOTIFY priorityChanged)
     Q_ENUMS(Priority)

 public:
     MyClass(QObject *parent = 0);
     ~MyClass();

     enum Priority { High, Low, VeryHigh, VeryLow };

     void setPriority(Priority priority)
     {
         m_priority = priority;
         emit priorityChanged(priority);
     }
     Priority priority() const
     { return m_priority; }

 signals:
     void priorityChanged(Priority);

 private:
     Priority m_priority;
 };
László Papp
  • 51,870
  • 39
  • 111
  • 135
dexterous
  • 6,422
  • 12
  • 51
  • 99

1 Answers1

14

It has the following advantages:

  • It is available for the meta object system, so it can be introspected, used from QML etc.

  • It has further options than just read and write. Look at notify, reset, etc. It is also easier to integrate them into QtCreator (designer).

  • You do not need to write the boilerplate with Qt 5.1 onwards in common read and write cases because they will be generated for you.

hyde
  • 60,639
  • 21
  • 115
  • 176
László Papp
  • 51,870
  • 39
  • 111
  • 135
  • Regarding first point, it can be introspected if it we have generated an interface. There is not need to specify the property there. Regarding QML, if we have declared Q_INVOKABLE or SLOT, then it can be invoked by QML. How QProperty affects there? Second point, I agree it can do more. Third point, I didn't understand. – dexterous Feb 23 '14 at 09:02
  • @SHREYASJOSHI: slot is usually used for void return values. Q_INVOKABLE would be tedious to write for each method. Moreover, introspection is not just about using it from QML, really, and even if you could do that, you would not use it as a real property from QML, but function calls. That would be annoying. Third point: it does not make sense to write your own getter/setter when it is usually the same boilerplate. Qt 5 will auto-generate it for you. – László Papp Feb 23 '14 at 09:05
  • 3
    +1 for *"do not need to write the boilerplate with Qt 5 in common read and write cases"*, didn't know about it. But do you have a link documenting that? (I couldn't find anything about that for example [here](http://qt-project.org/doc/qt-5.0/qtcore/properties.html).) – hyde Feb 23 '14 at 09:28
  • @hyde: nope, I just heard it on IRC back then. Check the source. ;-) – László Papp Feb 23 '14 at 09:32
  • Are you referring to generating setters and getters? I don't think there exists something like that, built-in the property system. – Frank Osterfeld Feb 23 '14 at 10:01
  • @hyde: actually, it *is* documented there, see `A MEMBER variable association is required if no READ accessor function is specified. This makes the given member variable readable and writable without the need of creating READ and WRITE accessor functions. It's still possible to use READ or WRITE accessor functions in addition to MEMBER variable association (but not both), if you need to control the variable access.` – László Papp Feb 23 '14 at 10:35
  • 1
    Interesting, good to know! The docs: http://qt-project.org/doc/qt-5/properties.html – Frank Osterfeld Feb 23 '14 at 10:37
  • @SHREYASJOSHI "Regarding first point, it can be introspected if it we have generated an interface. There is not need to specify the property there." What do you mean by "if we have generated an interface"? For a *static* property to be known to the meta object system, it must be declared using the Q_PROPERTY macro. This macro expands to nothing, but the moc code generator picks it up and generates relevant metadata. If there's no `Q_PROPERTY` macro, then the *static* property doesn't exist, as far as Qt meta object system is concerned. The dynamic properties are different of course. – Kuba hasn't forgotten Monica Feb 23 '14 at 17:36
  • So, the "secret" for avoiding boilerplate is `MEMBER`, which was actually first documented for [Qt 5.1](http://qt-project.org/doc/qt-5.1/qtcore/properties.html). I wonder if it was actually introduced in 5.0 but the docs weren't updated (and don't have 5.0 installed so can't test). – hyde Feb 24 '14 at 10:28
  • 1
    @hyde, no, it was introduced in 5.1 as per the aforementioned bugreport. Please read that, too. Here is the corresponding gerrit link: https://codereview.qt-project.org/#change,44645 – László Papp Feb 24 '14 at 10:35
  • By the way, it's pretty useful when styling custom widgets via css, you can write something like `MyWidget#id[myproperty='value'] { border: 1px solid red; }` – MasterAler Nov 25 '15 at 15:27