1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
/****************************************************************************
**
** Copyright (C) 2014 Ford Motor Company
** Contact: https://www.qt.io/licensing/
**
** This file is part of the QtRemoteObjects module of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:LGPL21$
** 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 The Qt Company. For licensing terms
** and conditions see http://www.qt.io/terms-conditions. For further
** information use the contact form at http://www.qt.io/contact-us.
**
** GNU Lesser General Public License Usage
** Alternatively, this file may be used under the terms of the GNU Lesser
** General Public License version 2.1 or version 3 as published by the Free
** Software Foundation and appearing in the file LICENSE.LGPLv21 and
** LICENSE.LGPLv3 included in the packaging of this file. Please review the
** following information to ensure the GNU Lesser General Public License
** requirements will be met: https://www.gnu.org/licenses/lgpl.html and
** http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
**
** As a special exception, The Qt Company gives you certain additional
** rights. These rights are described in The Qt Company LGPL Exception
** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
**
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\page qtremoteobjects-use.html
\title Using Qt Remote Objects
\brief Introduction to using Qt Remote Objects.
Consider a sensor, a global positioning system (GPS) receiver for instance. In
QtRO terms, the \l {Source} would be the process that directly interacts with
the GPS hardware and derives your current location. The location would be
exposed as QObject properties, and the periodic updates to the location would
update the properties and emit property changed signals. \l {Replica}s would be
created in other processes and would always know your current location, but
would not need any of the logic to compute the location from the sensor data.
Connecting to the location changed Signal on the \l {Replica} would work as
expected, as the signal emitted from the \l {Source} would trigger the Signal
emission on every \l {Replica}.
Another example of QtRO usage would be for a service (for example, access to a printer).
The \l {Source} is again the process controlling the printer directly. Here you
would again likely have properties monitoring the ink levels or whether the printer is
currently busy. However, the key feature, being able to print something, needs to be
passed back to the printer. This aligns with the Qt Slot mechanism, which QtRO
uses as the way for \l {Replica}s to make calls on the \l {Source}. In effect,
properties and signals go from \l {Source} to \l {Replica}s, while slots go
from (a) \l {Replica} to the \l {Source}. Assuming a print request is accepted,
the printer status would change, which would change the status property. This
would then be reported to all \l {Replica}s.
*/
|
