We don't have a custom destructor and the copy ctor/assignment operator don't do anything special, so the default one will do the right thing.
This is in accordance with the rule of zero (https://cpppatterns.com/patterns/rule-of-zero.html)
While mostly theoretical it makes for a more expressive API since it communicates that it is a list instead of a single value. It also allows to get rid of some conversion code.
This is also preparation work for potentially using the custom type capabilities that QtDBus offers.
This automatizes the generation of logging categories so a
kdeconnect-kde.categories is generated and installed to
/usr/share/qlogging-categories5/ so kdebugsettings can use it.
Also, sets the default logging level to Warning. So now the logs
of users won't be filled with debug messages but they can
modify the configuration easily with kdebugsettings.
This was removed to drop the notificationsplugin's "No icon" hack, but de facto all notifications have icons.
This makes sure that the KDE Connect entry in the notifications KCM has an icon
playerctld (https://github.com/altdesktop/playerctl/issues/161) is a proxy daemon for the currently active player by playerctl, which facilitates managing mpris players, forwarding requests to the currently active/last active player, and sorting out troubles with selecting the correct player manually.
Unfortunately, it also creates an annoying issue with kdeconnect: when playing media on the phone, kdeconnect publishes the state to the computer through the mprisremote plugin - then, playerctld picks it up as active player, and registers its own mpris media player. As a result, the mpriscontrol plugin sees this as a running media player, and in turn, publishes the state back to the phone, essentially creating another media session on the phone, resulting in two notifications. As playerctld is _always_ only a proxy to another media player (or kdeconnect), it can safely be ignored, just like kdeconnect itself already is. This commit adds an if check doing exactly that.
## Summary
The core idea is as follows:
1. When a Link loads the BatteryPlugin, we query Solid for a list of batteries.
1. If the list is empty, we print a warning message and return quickly
2. Otherwise, we connect *two signals* to every object in that list
2. We send out a single new NetworkPacket as soon as we've processed that list
3. When either of those two signals emits, we send another new NetworkPacket
### Multi-battery Support
BUG: 357193
To handle devices with multiple batteries (requested in that bug), we average
together the battery percentages. This also includes a new field in the packet for
'number of batteries' called `batteryQuantity`. For backwards compatibility, we can
assume it has a default value of one.
This should ensure we support
- devices with no batteries at all (like many desktop machines)
- devices with hot-pluggable batteries (like those laptops with detachable screens)
### Concerns
Note that the implementation isn't perfect.
We'll need some new localizable text to make it clear that we now support sending
battery status information.
Then there's a rather significant question: maybe we should have two battery plugins
on each client, like we do for the `findmyphone`/`findthisdevice` plugins?
## Test Plan
We need to ensure that other clients (including those using the Android codebase)
will respond correctly. The main things to look at are
1. are these new packets sent when the plugin is enabled, and not sent when it's disabled?
2. is the charge percentage accurate?
3. is the charge state (charging, discharging, or full) accurate?
and
4. do we see the correct number of warnings for low-battery?
