As discussed with Albert, move the population of capabilities into the
identity package, making them static along the execution of the link.
When we receive the identityPackage, we collect the plugins we can use with
the device and stick to those. This should simplify the implementation and
remove the possibility to lose packages if packages are received before the
capabilities are processed in the former approach.
REVIEW: 128386
Every time we reload the plugin list, report the plugins that we support.
If the remote devices' capabilities change, update the plugin list.
Reviewed by Albert Vaca
Removes the id->row mapping. It was broken as the indices weren't updated
when a row was added or removed.
Stop exposing Device::id through dbus, just store it in the interface
class.
* It's redundant as it's part of the interface definition
* If we keep it it will save us quite some dbus round-trips
* It will be reliable, as nowadays id() sometimes QString() if the dbus
connection is invalid.
REVIEW: 124158
Benefits:
- We had config files in different paths, now they will be centralized.
- Daemon, LanLinkProvider and NetworkPackage depend only on Qt now.
- KConfig is accessed with strings as keys, where a typo can go unnoticed.
- Daemon is now thinner, as it doesn't need to initialize config values.
- QCA::Initializer is in a single place now (was in Daemon and Plugin).
Only look for it in the writable path, as it won't ever be installed in a
common place.
Don't look for the path in the config file either.
Don't make it depend on the application name.
REVIEW: 122744
Only lets the plugins that support something offered on the other end or
that offer something supported on the other end. If we don't have
information about the other device, we enable everything like we used to.
Also refactors a bit the plugin loader, to be able to provide information
step by step.
Currently it works, but we need support for capabilities at least on
Android to start taking good advantage of it.
REVIEW: 118820
CCMAIL: kdeconnect@kde.org
