1 | /****************************************************************************
|
---|
2 | **
|
---|
3 | ** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
|
---|
4 | ** Contact: Qt Software Information ([email protected])
|
---|
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 [email protected].
|
---|
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 | */
|
---|