Doc: Moved content from qtdoc

- The qdoc pages were related to qtcore and they were
referring to snippets inside the qtcore module boundary.
- Fixed the exampledirs for QtCore to include the examples
that are referred by the \snippet instances in the
moved qdoc pages work.

Change-Id: Ibb6dbb131920ea8692a203f6145863e5012e4602
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
(cherry picked from commit 69e6029411)
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
This commit is contained in:
Venugopal Shivashankar 2012-12-14 14:19:43 +01:00 committed by The Qt Project
parent 4dc45567a0
commit 85338a9c63
4 changed files with 293 additions and 2 deletions

View File

@ -35,6 +35,8 @@ sourcedirs += ..
exampledirs += \
../ \
snippets \
../../../examples/threads
../../../examples/threads/ \
../../../examples/tools/ \
../../../examples/widgets/widgets/analogclock
imagedirs += images

View File

@ -0,0 +1,165 @@
/****************************************************************************
**
** Copyright (C) 2012 Digia Plc and/or its subsidiary(-ies).
** Contact: http://www.qt-project.org/legal
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and Digia. For licensing terms and
** conditions see http://qt.digia.com/licensing. For further information
** use the contact form at http://qt.digia.com/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: http://www.gnu.org/copyleft/fdl.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\page custom-types.html
\title Creating Custom Qt Types
\brief How to create and register new types with Qt.
\ingroup best-practices
\tableofcontents
\section1 Overview
When creating user interfaces with Qt, particularly those with specialized controls and
features, developers sometimes need to create new data types that can be used alongside
or in place of Qt's existing set of value types.
Standard types such as QSize, QColor and QString can all be stored in QVariant objects,
used as the types of properties in QObject-based classes, and emitted in signal-slot
communication.
In this document, we take a custom type and describe how to integrate it into Qt's object
model so that it can be stored in the same way as standard Qt types. We then show how to
register the custom type to allow it to be used in signals and slots connections.
\section1 Creating a Custom Type
Before we begin, we need to ensure that the custom type we are creating meets all the
requirements imposed by QMetaType. In other words, it must provide:
\list
\li a public default constructor,
\li a public copy constructor, and
\li a public destructor.
\endlist
The following \c Message class definition includes these members:
\snippet customtype/message.h custom type definition
The class also provides a constructor for normal use and two public member functions
that are used to obtain the private data.
\section1 Declaring the Type with QMetaType
The \c Message class only needs a suitable implementation in order to be usable.
However, Qt's type system will not be able to understand how to store, retrieve
and serialize instances of this class without some assistance. For example, we
will be unable to store \c Message values in QVariant.
The class in Qt responsible for custom types is QMetaType. To make the type known
to this class, we invoke the Q_DECLARE_METATYPE() macro on the class in the header
file where it is defined:
\snippet customtype/message.h custom type meta-type declaration
This now makes it possible for \c Message values to be stored in QVariant objects
and retrieved later. See the \l{Custom Type Example} for code that demonstrates
this.
The Q_DECLARE_METATYPE() macro also makes it possible for these values to be used as
arguments to signals, but \e{only in direct signal-slot connections}.
To make the custom type generally usable with the signals and slots mechanism, we
need to perform some extra work.
\section1 Creating and Destroying Custom Objects
Although the declaration in the previous section makes the type available for use
in direct signal-slot connections, it cannot be used for queued signal-slot
connections, such as those that are made between objects in different threads.
This is because the meta-object system does not know how to handle creation and
destruction of objects of the custom type at run-time.
To enable creation of objects at run-time, call the qRegisterMetaType() template
function to register it with the meta-object system. This also makes the type
available for queued signal-slot communication as long as you call it before you
make the first connection that uses the type.
The \l{Queued Custom Type Example} declares a \c Block class which is registered
in the \c{main.cpp} file:
\snippet queuedcustomtype/main.cpp main start
\dots
\snippet queuedcustomtype/main.cpp register meta-type for queued communications
\dots
\snippet queuedcustomtype/main.cpp main finish
This type is later used in a signal-slot connection in the \c{window.cpp} file:
\snippet queuedcustomtype/window.cpp Window constructor start
\dots
\snippet queuedcustomtype/window.cpp connecting signal with custom type
\dots
\snippet queuedcustomtype/window.cpp Window constructor finish
If a type is used in a queued connection without being registered, a warning will be
printed at the console; for example:
\code
QObject::connect: Cannot queue arguments of type 'Block'
(Make sure 'Block' is registered using qRegisterMetaType().)
\endcode
\section1 Making the Type Printable
It is often quite useful to make a custom type printable for debugging purposes,
as in the following code:
\snippet customtype/main.cpp printing a custom type
This is achieved by creating a streaming operator for the type, which is often
defined in the header file for that type:
\snippet customtype/message.h custom type streaming operator
The implementation for the \c Message type in the \l{Custom Type Example}
goes to some effort to make the printable representation as readable as
possible:
\snippet customtype/message.cpp custom type streaming operator
The output sent to the debug stream can, of course, be made as simple or as
complicated as you like. Note that the value returned by this function is
the QDebug object itself, though this is often obtained by calling the
maybeSpace() member function of QDebug that pads out the stream with space
characters to make it more readable.
\section1 Further Reading
The Q_DECLARE_METATYPE() macro and qRegisterMetaType() function documentation
contain more detailed information about their uses and limitations.
The \l{Custom Type Example}{Custom Type},
\l{Custom Type Sending Example}{Custom Type Sending}
and \l{Queued Custom Type Example}{Queued Custom Type} examples show how to
implement a custom type with the features outlined in this document.
The \l{Debugging Techniques} document provides an overview of the debugging
mechanisms discussed above.
*/

View File

@ -47,7 +47,7 @@
properties}
\li powerful \l{The Event System}{events and event filters}
\li contextual \l{i18n}{string translation for internationalization}
\li sophisticated interval driven \l timers that make it possible
\li sophisticated interval driven \l {Timers}{timers} that make it possible
to elegantly integrate many tasks in an event-driven GUI
\li hierarchical and queryable \l{Object Trees & Ownership}{object
trees} that organize object ownership in a natural way
@ -56,6 +56,7 @@
pointers which become dangling pointers when their objects are destroyed
\li a \l{metaobjects.html#qobjectcast}{dynamic cast} that works across
library boundaries.
\li support for \l{Creating Custom Qt Types}{custom type} creation.
\endlist
Many of these Qt features are implemented with standard C++

View File

@ -0,0 +1,123 @@
/****************************************************************************
**
** Copyright (C) 2012 Digia Plc and/or its subsidiary(-ies).
** Contact: http://www.qt-project.org/legal
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and Digia. For licensing terms and
** conditions see http://qt.digia.com/licensing. For further information
** use the contact form at http://qt.digia.com/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: http://www.gnu.org/copyleft/fdl.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\page timers.html
\title Timers
\brief How to use Qt timers in your application.
\ingroup best-practices
QObject, the base class of all Qt objects, provides the basic
timer support in Qt. With QObject::startTimer(), you start a
timer with an interval in milliseconds as argument. The function
returns a unique integer timer ID. The timer will now fire at
regular intervals until you explicitly call QObject::killTimer()
with the timer ID.
For this mechanism to work, the application must run in an event
loop. You start an event loop with QApplication::exec(). When a
timer fires, the application sends a QTimerEvent, and the flow of
control leaves the event loop until the timer event is processed.
This implies that a timer cannot fire while your application is
busy doing something else. In other words: the accuracy of timers
depends on the granularity of your application.
In multithreaded applications, you can use the timer mechanism in
any thread that has an event loop. To start an event loop from a
non-GUI thread, use QThread::exec(). Qt uses the object's
\l{QObject::thread()}{thread affinity} to determine which thread
will deliver the QTimerEvent. Because of this, you must start and
stop all timers in the object's thread; it is not possible to
start timers for objects in another thread.
The upper limit for the interval value is determined by the number
of milliseconds that can be specified in a signed integer
(in practice, this is a period of just over 24 days). The accuracy
depends on the underlying operating system. Windows 2000 has 15
millisecond accuracy; other systems that we have tested can handle
1 millisecond intervals.
The main API for the timer functionality is QTimer. That class
provides regular timers that emit a signal when the timer fires, and
inherits QObject so that it fits well into the ownership structure
of most GUI programs. The normal way of using it is like this:
\snippet timers/timers.cpp 0
\snippet timers/timers.cpp 1
\snippet timers/timers.cpp 2
The QTimer object is made into a child of this widget so that,
when this widget is deleted, the timer is deleted too.
Next, its \l{QTimer::}{timeout()} signal is connected to the slot
that will do the work, it is started with a value of 1000
milliseconds, indicating that it will time out every second.
QTimer also provides a static function for single-shot timers.
For example:
\snippet timers/timers.cpp 3
200 milliseconds (0.2 seconds) after this line of code is
executed, the \c updateCaption() slot will be called.
For QTimer to work, you must have an event loop in your
application; that is, you must call QCoreApplication::exec()
somewhere. Timer events will be delivered only while the event
loop is running.
In multithreaded applications, you can use QTimer in any thread
that has an event loop. To start an event loop from a non-GUI
thread, use QThread::exec(). Qt uses the timer's
\l{QObject::thread()}{thread affinity} to determine which thread
will emit the \l{QTimer::}{timeout()} signal. Because of this, you
must start and stop the timer in its thread; it is not possible to
start a timer from another thread.
The \l{widgets/analogclock}{Analog Clock} example shows how to use
QTimer to redraw a widget at regular intervals. From \c{AnalogClock}'s
implementation:
\snippet analogclock.cpp 0
\snippet analogclock.cpp 2
\snippet analogclock.cpp 3
\snippet analogclock.cpp 4
\snippet analogclock.cpp 5
\snippet analogclock.cpp 6
\dots
\snippet analogclock.cpp 7
Every second, QTimer will call the QWidget::update() slot to
refresh the clock's display.
If you already have a QObject subclass and want an easy
optimization, you can use QBasicTimer instead of QTimer. With
QBasicTimer, you must reimplement
\l{QObject::timerEvent()}{timerEvent()} in your QObject subclass
and handle the timeout there. The \l{widgets/wiggly}{Wiggly}
example shows how to use QBasicTimer.
*/