| 1 | /**************************************************************************** | 
|---|
| 2 | ** | 
|---|
| 3 | ** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies). | 
|---|
| 4 | ** Contact: Qt Software Information (qt-info@nokia.com) | 
|---|
| 5 | ** | 
|---|
| 6 | ** This file is part of the documentation of the Qt Toolkit. | 
|---|
| 7 | ** | 
|---|
| 8 | ** $QT_BEGIN_LICENSE:LGPL$ | 
|---|
| 9 | ** Commercial Usage | 
|---|
| 10 | ** Licensees holding valid Qt Commercial licenses may use this file in | 
|---|
| 11 | ** accordance with the Qt Commercial License Agreement provided with the | 
|---|
| 12 | ** Software or, alternatively, in accordance with the terms contained in | 
|---|
| 13 | ** a written agreement between you and Nokia. | 
|---|
| 14 | ** | 
|---|
| 15 | ** GNU Lesser General Public License Usage | 
|---|
| 16 | ** Alternatively, this file may be used under the terms of the GNU Lesser | 
|---|
| 17 | ** General Public License version 2.1 as published by the Free Software | 
|---|
| 18 | ** Foundation and appearing in the file LICENSE.LGPL included in the | 
|---|
| 19 | ** packaging of this file.  Please review the following information to | 
|---|
| 20 | ** ensure the GNU Lesser General Public License version 2.1 requirements | 
|---|
| 21 | ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. | 
|---|
| 22 | ** | 
|---|
| 23 | ** In addition, as a special exception, Nokia gives you certain | 
|---|
| 24 | ** additional rights. These rights are described in the Nokia Qt LGPL | 
|---|
| 25 | ** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this | 
|---|
| 26 | ** package. | 
|---|
| 27 | ** | 
|---|
| 28 | ** GNU General Public License Usage | 
|---|
| 29 | ** Alternatively, this file may be used under the terms of the GNU | 
|---|
| 30 | ** General Public License version 3.0 as published by the Free Software | 
|---|
| 31 | ** Foundation and appearing in the file LICENSE.GPL included in the | 
|---|
| 32 | ** packaging of this file.  Please review the following information to | 
|---|
| 33 | ** ensure the GNU General Public License version 3.0 requirements will be | 
|---|
| 34 | ** met: http://www.gnu.org/copyleft/gpl.html. | 
|---|
| 35 | ** | 
|---|
| 36 | ** If you are unsure which license is appropriate for your use, please | 
|---|
| 37 | ** contact the sales department at qt-sales@nokia.com. | 
|---|
| 38 | ** $QT_END_LICENSE$ | 
|---|
| 39 | ** | 
|---|
| 40 | ****************************************************************************/ | 
|---|
| 41 |  | 
|---|
| 42 | /*! | 
|---|
| 43 | \page properties.html | 
|---|
| 44 | \title Qt's Property System | 
|---|
| 45 | \ingroup architecture | 
|---|
| 46 | \brief An overview of Qt's property system. | 
|---|
| 47 |  | 
|---|
| 48 | Qt provides a sophisticated property system similar to the ones | 
|---|
| 49 | supplied by some compiler vendors. However, as a compiler- and | 
|---|
| 50 | platform-independent library, Qt does not rely on non-standard | 
|---|
| 51 | compiler features like \c __property or \c [property]. The Qt | 
|---|
| 52 | solution works with \e any standard C++ compiler on every platform | 
|---|
| 53 | Qt supports. It is based on the \l {Meta-Object System} that also | 
|---|
| 54 | provides inter-object communication via \l{signals and slots}. | 
|---|
| 55 |  | 
|---|
| 56 | \section1 Requirements for Declaring Properties | 
|---|
| 57 |  | 
|---|
| 58 | To declare a property, use the \l {Q_PROPERTY()} {Q_PROPERTY()} | 
|---|
| 59 | macro in a class that inherits QObject. | 
|---|
| 60 |  | 
|---|
| 61 | \snippet doc/src/snippets/code/doc_src_properties.qdoc 0 | 
|---|
| 62 |  | 
|---|
| 63 | Here are some typical examples of property declarations taken from | 
|---|
| 64 | class QWidget. | 
|---|
| 65 |  | 
|---|
| 66 | \snippet doc/src/snippets/code/doc_src_properties.qdoc 1 | 
|---|
| 67 |  | 
|---|
| 68 | A property behaves like a class data member, but it has additional | 
|---|
| 69 | features accessible through the \l {Meta-Object System}. | 
|---|
| 70 |  | 
|---|
| 71 | \list | 
|---|
| 72 |  | 
|---|
| 73 | \o A \c READ accessor function is required. It is for reading the | 
|---|
| 74 | property value. It must be const and must return either the | 
|---|
| 75 | property's type or a pointer or reference to that type. e.g., | 
|---|
| 76 | QWidget::focus is a read-only property with \c READ function | 
|---|
| 77 | QWidget::hasFocus(). | 
|---|
| 78 |  | 
|---|
| 79 | \o A \c WRITE accessor function is optional. It is for setting the | 
|---|
| 80 | property value. It must return void and must take exactly one | 
|---|
| 81 | argument, either of the property's type or a pointer or reference | 
|---|
| 82 | to that type. e.g., QWidget::enabled has the \c WRITE function | 
|---|
| 83 | QWidget::setEnabled().  Read-only properties do not need \c WRITE | 
|---|
| 84 | functions. e.g., QWidget::focus has no \c WRITE function. | 
|---|
| 85 |  | 
|---|
| 86 | \o A \c RESET function is optional. It is for setting the property | 
|---|
| 87 | back to its context specific default value. e.g., QWidget::cursor | 
|---|
| 88 | has the typical \c READ and \c WRITE functions, QWidget::cursor() | 
|---|
| 89 | and QWidget::setCursor(), and it also has a \c RESET function, | 
|---|
| 90 | QWidget::unsetCursor(), since no call to QWidget::setCursor() can | 
|---|
| 91 | mean \e {reset to the context specific cursor}. The \c RESET | 
|---|
| 92 | function musrt return void and take no parameters. | 
|---|
| 93 |  | 
|---|
| 94 | \o The \c DESIGNABLE attribute indicates whether the property | 
|---|
| 95 | should be visible in the property editor of GUI design tool (e.g., | 
|---|
| 96 | \l {Qt Designer}). Most properties are \c DESIGNABLE (default | 
|---|
| 97 | true). Instead of true or false, you can specify a boolean | 
|---|
| 98 | member function. | 
|---|
| 99 |  | 
|---|
| 100 | \o The \c SCRIPTABLE attribute indicates whether this property | 
|---|
| 101 | should be accessible by a scripting engine (default true). | 
|---|
| 102 | Instead of true or false, you can specify a boolean member | 
|---|
| 103 | function. | 
|---|
| 104 |  | 
|---|
| 105 | \o The \c STORED attribute indicates whether the property should | 
|---|
| 106 | be thought of as existing on its own or as depending on other | 
|---|
| 107 | values. It also indicates whether the property value must be saved | 
|---|
| 108 | when storing the object's state. Most properties are \c STORED | 
|---|
| 109 | (default true), but e.g., QWidget::minimumWidth() has \c STORED | 
|---|
| 110 | false, because its value is just taken from the width component | 
|---|
| 111 | of property QWidget::minimumSize(), which is a QSize. | 
|---|
| 112 |  | 
|---|
| 113 | \o The \c USER attribute indicates whether the property is | 
|---|
| 114 | designated as the user-facing or user-editable property for the | 
|---|
| 115 | class. Normally, there is only one \c USER property per class | 
|---|
| 116 | (default false). e.g., QAbstractButton::checked is the user | 
|---|
| 117 | editable property for (checkable) buttons. Note that QItemDelegate | 
|---|
| 118 | gets and sets a widget's \c USER property. | 
|---|
| 119 |  | 
|---|
| 120 | \endlist | 
|---|
| 121 |  | 
|---|
| 122 | The \c READ, \c WRITE, and \c RESET functions can be inherited. | 
|---|
| 123 | They can also be virtual. When they are inherited in classes where | 
|---|
| 124 | multiple inheritance is used, they must come from the first | 
|---|
| 125 | inherited class. | 
|---|
| 126 |  | 
|---|
| 127 | The property type can be any type supported by QVariant, or it can | 
|---|
| 128 | be a user-defined type. In this example, class QDate is considered | 
|---|
| 129 | to be a user-defined type. | 
|---|
| 130 |  | 
|---|
| 131 | \snippet doc/src/snippets/code/doc_src_properties.qdoc 2 | 
|---|
| 132 |  | 
|---|
| 133 | Because QDate is user-defined, you must include the \c{<QDate>} | 
|---|
| 134 | header file with the property declaration. | 
|---|
| 135 |  | 
|---|
| 136 | For QMap, QList, and QValueList properties, the property value is | 
|---|
| 137 | a QVariant whose value is the entire list or map.  Note that the | 
|---|
| 138 | Q_PROPERTY string cannot contain commas, because commas separate | 
|---|
| 139 | macro arguments. Therefore, you must use \c QMap as the property | 
|---|
| 140 | type instead of \c QMap<QString,QVariant>. For consistency, also | 
|---|
| 141 | use \c QList and \c QValueList instead of \c QList<QVariant> and | 
|---|
| 142 | \c QValueList<QVariant>. | 
|---|
| 143 |  | 
|---|
| 144 | \section1 Reading and Writing Properties with the Meta-Object System | 
|---|
| 145 |  | 
|---|
| 146 | A property can be read and written using the generic functions | 
|---|
| 147 | QObject::property() and QObject::setProperty(), without knowing | 
|---|
| 148 | anything about the owning class except the property's name.  In | 
|---|
| 149 | the code snippet below, the call to QAbstractButton::setDown() and | 
|---|
| 150 | the call to QObject::setProperty() both set property "down". | 
|---|
| 151 |  | 
|---|
| 152 | \snippet doc/src/snippets/code/doc_src_properties.qdoc 3 | 
|---|
| 153 |  | 
|---|
| 154 | Accessing a property through its \c WRITE accessor is the better | 
|---|
| 155 | of the two, because it is faster and gives better diagnostics at | 
|---|
| 156 | compile time, but setting the property this way requires that you | 
|---|
| 157 | know about the class at compile time. Accessing properties by name | 
|---|
| 158 | lets you access classes you don't know about at compile time. You | 
|---|
| 159 | can \e discover a class's properties at run time by querying its | 
|---|
| 160 | QObject, QMetaObject, and \l {QMetaProperty} {QMetaProperties}. | 
|---|
| 161 |  | 
|---|
| 162 | \snippet doc/src/snippets/code/doc_src_properties.qdoc 4 | 
|---|
| 163 |  | 
|---|
| 164 | In the above snippet, QMetaObject::property() is used to get \l | 
|---|
| 165 | {QMetaProperty} {metadata} about each property defined in some | 
|---|
| 166 | unknown class. The property name is fetched from the metadata and | 
|---|
| 167 | passed to QObject::property() to get the \l {QVariant} {value} of | 
|---|
| 168 | the property in the current \l {QObject}{object}. | 
|---|
| 169 |  | 
|---|
| 170 | \section1 A Simple Example | 
|---|
| 171 |  | 
|---|
| 172 | Suppose we have a class MyClass, which is derived from QObject and | 
|---|
| 173 | which uses the Q_OBJECT macro in its private section. We want to | 
|---|
| 174 | declare a property in MyClass to keep track of a priorty | 
|---|
| 175 | value. The name of the property will be \e priority, and its type | 
|---|
| 176 | will be an enumeration type named \e Priority, which is defined in | 
|---|
| 177 | MyClass. | 
|---|
| 178 |  | 
|---|
| 179 | We declare the property with the Q_PROPERTY() macro in the private | 
|---|
| 180 | section of the class. The required \c READ function is named \c | 
|---|
| 181 | priority, and we include a \c WRITE function named \c setPriority. | 
|---|
| 182 | The enumeration type must be registered with the \l {Meta-Object | 
|---|
| 183 | System} using the Q_ENUMS() macro. Registering an enumeration type | 
|---|
| 184 | makes the enumerator names available for use in calls to | 
|---|
| 185 | QObject::setProperty(). We must also provide our own declarations | 
|---|
| 186 | for the \c READ and \c WRITE functions. The declaration of MyClass | 
|---|
| 187 | then might look like this: | 
|---|
| 188 |  | 
|---|
| 189 | \snippet doc/src/snippets/code/doc_src_properties.qdoc 5 | 
|---|
| 190 |  | 
|---|
| 191 | The \c READ function is const and returns the property type. The | 
|---|
| 192 | \c WRITE function returns void and has exactly one parameter of | 
|---|
| 193 | the property type. The meta-object compiler enforces these | 
|---|
| 194 | requirements. | 
|---|
| 195 |  | 
|---|
| 196 | Given a pointer to an instance of MyClass or a pointer to an | 
|---|
| 197 | instance of QObject that happens to be an instance of MyClass, we | 
|---|
| 198 | have two ways to set its priority property. | 
|---|
| 199 |  | 
|---|
| 200 | \snippet doc/src/snippets/code/doc_src_properties.qdoc 6 | 
|---|
| 201 |  | 
|---|
| 202 | In the example, the enumeration type used for the property type | 
|---|
| 203 | was locally declared in MyClass. Had it been declared in another | 
|---|
| 204 | class, its fully qualified name (i.e., OtherClass::Priority) would | 
|---|
| 205 | be required.  In addition, that other class must also inherit | 
|---|
| 206 | QObject and register the enum type using Q_ENUMS(). | 
|---|
| 207 |  | 
|---|
| 208 | A similar macro, Q_FLAGS(), is also available. Like Q_ENUMS(), it | 
|---|
| 209 | registers an enumeration type, but it marks the type as being a | 
|---|
| 210 | set of \e flags, i.e. values that can be OR'd together. An I/O | 
|---|
| 211 | class might have enumeration values \c Read and \c Write and then | 
|---|
| 212 | QObject::setProperty() could accept \c{Read | Write}. Q_FLAGS() | 
|---|
| 213 | should be used to register this enumeration type. | 
|---|
| 214 |  | 
|---|
| 215 | \section1 Dynamic Properties | 
|---|
| 216 |  | 
|---|
| 217 | QObject::setProperty() can also be used to add \e new properties | 
|---|
| 218 | to an instance of a class at runtime. When it is called with a | 
|---|
| 219 | name and a value, if a property with the given name exists in the | 
|---|
| 220 | QObject, and if the given value is compatible with the property's | 
|---|
| 221 | type, the value is stored in the property, and true is returned. | 
|---|
| 222 | If the value is \e not compatible with the property's type, the | 
|---|
| 223 | property is \e not changed, and false is returned. But if the | 
|---|
| 224 | property with the given name doesn't exist in the QObject (i.e., | 
|---|
| 225 | if it wasn't declared with Q_PROPERTY(), a new property with the | 
|---|
| 226 | given name and value is automatically added to the QObject, but | 
|---|
| 227 | false is still returned. This means that a return of false can't | 
|---|
| 228 | be used to determine whether a particular property was actually | 
|---|
| 229 | set, unless you know in advance that the property already exists | 
|---|
| 230 | in the QObject. | 
|---|
| 231 |  | 
|---|
| 232 | Note that \e dynamic properties are added on a per instance basis, | 
|---|
| 233 | i.e., they are added to QObject, not QMetaObject. A property can | 
|---|
| 234 | be removed from an instance by passing the property name and an | 
|---|
| 235 | invalid QVariant value to QObject::setProperty(). The default | 
|---|
| 236 | constructor for QVariant constructs an invalid QVariant. | 
|---|
| 237 |  | 
|---|
| 238 | Dynamic properties can be queried with QObject::property(), just | 
|---|
| 239 | like properties declared at compile time with Q_PROPERTY(). | 
|---|
| 240 |  | 
|---|
| 241 | \sa {Meta-Object System}, {Signals and Slots} | 
|---|
| 242 |  | 
|---|
| 243 | \section1 Properties and Custom Types | 
|---|
| 244 |  | 
|---|
| 245 | Custom types used by properties need to be registered using the | 
|---|
| 246 | Q_DECLARE_METATYPE() macro so that their values can be stored in | 
|---|
| 247 | QVariant objects. This makes them suitable for use with both | 
|---|
| 248 | static properties declared using the Q_PROPERTY() macro in class | 
|---|
| 249 | definitions and dynamic properties created at run-time. | 
|---|
| 250 |  | 
|---|
| 251 | \sa Q_DECLARE_METATYPE(), QMetaType, QVariant | 
|---|
| 252 |  | 
|---|
| 253 | \section1 Adding Additional Information to a Class | 
|---|
| 254 |  | 
|---|
| 255 | Connected to the property system is an additional macro, | 
|---|
| 256 | Q_CLASSINFO(), that can be used to attach additional | 
|---|
| 257 | \e{name}--\e{value} pairs to a class's meta-object, for example: | 
|---|
| 258 |  | 
|---|
| 259 | \snippet doc/src/snippets/code/doc_src_properties.qdoc 7 | 
|---|
| 260 |  | 
|---|
| 261 | Like other meta-data, class information is accessible at run-time | 
|---|
| 262 | through the meta-object; see QMetaObject::classInfo() for details. | 
|---|
| 263 | */ | 
|---|