Multi-platform app that allows your devices to communicate
dbea3171bd
This meant to add a lot of dependencies to each plugin since we had KDELibs4support as PUBLIC link meaning that anything linking against kdeconnectcore was linking at the same time to mostly all frameworks. Now each plugin has more or less its dependencies in the CMake some still depend on KDELibs4Support. For the mousepad plugin I needed to add a fixX11.h file that basically undefines/defines again some stuff xlib has that conflcits with normal C++ and Qt. Before it was not conflicting because some lib within KDELibs4Support was including this file, but now we have to do it ourselves. |
||
|---|---|---|
| cli | ||
| cmake | ||
| core | ||
| fileitemactionplugin | ||
| icon | ||
| interfaces | ||
| kcm | ||
| kded | ||
| kio | ||
| plasmoid | ||
| plugins | ||
| tests | ||
| .gitignore | ||
| .reviewboardrc | ||
| CMakeLists.txt | ||
| COPYING | ||
| README | ||
Class diagram
==============
Backend_1 ... Backend_N
\ | /
Daemon
/ | \
Device_1 ... Device_N
/ \
|-Plugin_1 |-DeviceLink_1
|-Plugin_2 |-DeviceLink_2
|- ... |-...
|-Plugin_N |-DeviceLink_N
Daemon instantiates Backends
Backends manage to create DeviceLinks with the devices they can reach, and Q_EMIT them to the Daemon.
When the Daemon receives a DeviceLink from a backend:
- If it already knows the Device, adds the new DeviceLink to the existing Device, as a new way to reach it.
- If not, it creates a new untrusted (yet to be paired) Device.
Devices contain a list of DeviceLinks, plus a list of Plugins (instantiated automatically)
Information for and from Plugins is encapsulated in NetworkPackages.
When a DeviceLink receives a NetworkPackage from the device in the other end, Device will notify all the plugins.
When a Plugin wants to send a NetworkPackage, it does so using the pointer to Device
The NetworkPackage format
=========================
NetworkPackages are independent and self-contained pieces of information that
are sent from one device to another (via a DeviceLink) serialized in json.
The basic structure of a NetworkPackage is the following:
{
"id": 123456789,
"type": "org.kde.whatever",
"body": {
},
"version": 5
}
Each type of package defines what it should contain inside its "body", so only
the emisor plugin and receiver plugin of this type of package need agree about
its content. Each plugin should provide a README explaining what does it write
in the "body" section, to ease porting to other platforms.
If the package has a payload attached, it will also contain two more fields:
"payloadSize": The size of the file, or -1 if it is a stream without known end
"payloadTransferInfo": Another JSON Object containing the information that the
backend wants to send to the peer backend, to actually
transfer the payload.
Encrypted network packages have the following format:
"type": is always set to "kdeconnect.encrypted".
"id": contains a new valid id (ie: not the same id as the unencrypted package).
"version": contains the package version.
"body": contains a "data" array that carries the original package encrypted.
The "data" array is filled the following way:
1. The original package is serialized.
2. The serialized string is divided in chunks small enough to be encrypted with
the other device's public key.
3. Each chunk is encrypted and appended to the array in order.