| CMakeLists.txt |
|
2925 |
- |
| configure.cmake |
|
565 |
- |
| doc |
|
|
- |
| qconnection_local_backend.cpp |
|
5264 |
- |
| qconnection_local_backend_p.h |
|
2487 |
- |
| qconnection_qnx_backend.cpp |
|
3986 |
- |
| qconnection_qnx_backend_p.h |
!
QtRO provides QtROClientIoDevice, QtROServerIoDevice and QConnectionAbstractServer
as abstract interfaces to allow different backends to be used by QtRO. The
concept behind these classes is that there needs to be a Host node, which
has an address that can be connected to. Then there is a client object,
which can be publicly constructed, and can connect to the server. When the
server gets a connection request, it creates the server side of the
connection, which communicates directly with the client. There are thus
three abstractions, one for the server, one for the client-side of the
connection, and the third for the server-side of the connection. The later
two need to inherit from QIODevice.
Creating a backend for something that is already implemented in Qt is a
matter of creating the three needed abstractions. In the case of creating a
QNX backend using QNX's Native Messaging, the backend needs to create the
Server (which has an address for accepting connections), the client
QIODevice, and the server side QIODevice. Since Native Messaging is one
way, and recommends using pulses to support two-way communication, the
logic for the client-side and server-side QIODevice are very different.
Thus, three additional backend classes are needed as well.
QnxClientIo implements the QtRO QtROClientIoDevice wrapper around the QNX
specific QQnxNativeIo QIODevice (the client-side QIODevice).
QnxServerIo implements the QtRO QtROServerIoDevice wrapper around the QNX
specific QIOQnxSource QIODevice (the server-side QIODevice).
QnxServerImpl implements the QtRO QConnectionAbstractServer wrapper around
the QNX specific QQnxNativeServer, which is the server object listening for
connections.
Not sure if it is of interest to the Qt community, but it seems like
QQnxNativeIo, QIOQnxSource and QQnxNativeServer could used as an optimized
QLocalServer/QLocalSocket QPA for QNX.
|
4061 |
- |
| qconnection_qnx_global_p.h |
|
2471 |
- |
| qconnection_qnx_qiodevices.cpp |
|
16467 |
- |
| qconnection_qnx_qiodevices.h |
The implementation of the Source and Replica
side QIODevice look like they will be fairly
different, including different APIs. So
creating a 2nd derived type for the source.
TODO: revisit if these can be combined into a
single type.
With two types, QQnxNativeIo will need to get
Source or Replica added. Not sure what intuitive
names are yet. So for now, QQnxNativeIo is the
Replica side, QIOQnxSourcePrivate is the Source
side. Revisit the name as this matures.
|
3510 |
- |
| qconnection_qnx_qiodevices_p.h |
|
1799 |
- |
| qconnection_qnx_server.cpp |
we received a pulse
|
18244 |
- |
| qconnection_qnx_server.h |
|
1144 |
- |
| qconnection_qnx_server_p.h |
|
1898 |
- |
| qconnection_tcpip_backend.cpp |
|
4606 |
- |
| qconnection_tcpip_backend_p.h |
|
2095 |
- |
| qconnectionfactories.cpp |
All communication between nodes happens through some form of QIODevice with
an associated QDataStream to handle marshalling of Qt types. QtROIoDeviceBase
is an abstract base class that provides a consistent interface to QtRO, yet
can be extended to support different types of QIODevice.
|
9802 |
- |
| qconnectionfactories.h |
|
5690 |
- |
| qconnectionfactories_p.h |
|
2248 |
- |
| qremoteobjectabstractitemmodeladapter.cpp |
|
11503 |
- |
| qremoteobjectabstractitemmodeladapter_p.h |
|
14009 |
- |
| qremoteobjectabstractitemmodelreplica.cpp |
|
44426 |
- |
| qremoteobjectabstractitemmodelreplica.h |
|
2240 |
- |
| qremoteobjectabstractitemmodelreplica_p.h |
|
16369 |
- |
| qremoteobjectabstractitemmodeltypes_p.h |
|
7503 |
- |
| qremoteobjectcontainers.cpp |
|
4870 |
- |
| qremoteobjectcontainers_p.h |
|
2798 |
- |
| qremoteobjectdynamicreplica.cpp |
!
\class QRemoteObjectDynamicReplica
\inmodule QtRemoteObjects
\brief A dynamically instantiated \l {Replica}.
There are generated replicas (replicas having the header files produced by
the \l {repc} {Replica Compiler}), and dynamic replicas, that are generated
on-the-fly. This is the class for the dynamic type of replica.
When the connection to the \l {Source} object is made, the initialization
step passes the current property values (see \l {Replica Initialization}).
In a DynamicReplica, the property/signal/slot details are also sent,
allowing the replica object to be created on-the-fly. This can be convenient
in QML or scripting, but has two primary disadvantages. First, the object is
in effect "empty" until it is successfully initialized by the \l {Source}.
Second, in C++, calls must be made using QMetaObject::invokeMethod(), as the
moc generated lookup will not be available.
This class does not have a public constructor. It can only be instantiated
by using the dynamic QRemoteObjectNode::acquire method.
|
7027 |
- |
| qremoteobjectdynamicreplica.h |
|
896 |
- |
| qremoteobjectnode.cpp |
|
124404 |
- |
| qremoteobjectnode.h |
|
8304 |
- |
| qremoteobjectnode_p.h |
|
7961 |
- |
| qremoteobjectpacket.cpp |
|
46303 |
- |
| qremoteobjectpacket_p.h |
|
10638 |
- |
| qremoteobjectpendingcall.cpp |
!
\class QRemoteObjectPendingCall
\inmodule QtRemoteObjects
\brief Encapsulates the result of an asynchronous method call.
|
6346 |
- |
| qremoteobjectpendingcall.h |
|
2489 |
- |
| qremoteobjectpendingcall_p.h |
|
1500 |
- |
| qremoteobjectregistry.cpp |
!
\class QRemoteObjectRegistry
\inmodule QtRemoteObjects
\brief A class holding information about \l {Source} objects available on the Qt Remote Objects network.
The Registry is a special Source/Replica pair held by a \l
{QRemoteObjectNode} {node} itself. It knows about all other \l {Source}s
available on the network, and simplifies the process of connecting to other
\l {QRemoteObjectNode} {node}s.
|
7667 |
- |
| qremoteobjectregistry.h |
|
1710 |
- |
| qremoteobjectregistrysource.cpp |
erasing |
2076 |
- |
| qremoteobjectregistrysource_p.h |
|
1392 |
- |
| qremoteobjectreplica.cpp |
|
36428 |
- |
| qremoteobjectreplica.h |
|
2393 |
- |
| qremoteobjectreplica_p.h |
|
6740 |
- |
| qremoteobjectrepparser.cpp |
Helper method to capitalize the first letter of a QString and return
the result as a QByteArray
|
8037 |
- |
| qremoteobjectrepparser_p.h |
These methods use a POD or Class definition from RepParser to dynamically create QMetaObject
definitions and (for PODs and enums) register them with Qt's type system. This requires memory
allocation, so cleanup is handled by passing a QObject pointer as a reference object. When the
QObject is destroyed, memory will be freed. This supports multiple QObjects referring to the
same type, so the addTracker method is provided to set additional QObjects as references. Memory
will be freed only when the last reference is destroyed.
If creation fails, a nullptr is returned.
|
1718 |
- |
| qremoteobjectsettingsstore.cpp |
!
\qmltype SettingsStore
\inqmlmodule QtRemoteObjects
\brief A basic store for persisted properties.
This type provides simple QSettings-based storage for properties marked as PERSISTED. It is used in
conjunction with Node::persistedStore:
\code
Node {
persistedStore: SettingsStore {}
}
\endcode
|
2106 |
- |
| qremoteobjectsettingsstore.h |
|
934 |
- |
| qremoteobjectsource.cpp |
|
27636 |
- |
| qremoteobjectsource.h |
|
6824 |
- |
| qremoteobjectsource_p.h |
|
6924 |
- |
| qremoteobjectsourceio.cpp |
|
15045 |
- |
| qremoteobjectsourceio_p.h |
|
2654 |
- |
| qremoteobjectstructs_p.h |
|
1718 |
- |
| Qt5RemoteObjectsConfigExtras.cmake.in |
|
1082 |
- |
| Qt6RemoteObjectsMacros.cmake |
|
7417 |
- |
| qtremoteobjectglobal.cpp |
!
\namespace QtRemoteObjects
\inmodule QtRemoteObjects
\brief The QtRemoteObjects namespace contains identifiers used in the
Remote Objects module, as well as some functions used from code generated
by the \l{Qt Remote Objects Compiler}{Replica Compiler (repc)}.
|
3112 |
- |
| qtremoteobjectglobal.h |
not exported |
4362 |
- |