The moc process already rebuilds the plugin when the JSON file changes, consequently the additional parameter is not needed.
Task: https://phabricator.kde.org/T14649
timeToEmpty in UPower is unreliable, e.g. it's always 0 on the PinePhone.
Instead warn when the percentage drops below 15%. That's how it is for Android anyway.
Instead of having the DBus stuff in a separate class expose the plugin class itself like we do for the other plugins.
Replace the method-based API with properties.
Change the path to <device>/battery for consistency with other plugins
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.
## 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?
Summary:
Below is a lost of the commits, but, in summary
Port the build system for Sailfish, which means selectively building only the bits we need/can, and only against the KF5 libs that are available.
Allow to build on Qt 5.6
Switch from knotification to nemo notification (not complete!)
Add a very simple example sailfish app.
Note, there is still much missing functionality. Notifications dont work, pairing sort of works but not really, but when it is paired you can send a ping to the desktop client
Dont build kio for Sailfish
Port core build system
Port daemon buld system
Require CoreAddons on Sailfish
Port plugins build for sailfish and include the ping plugin for now
Final build changes for sailfish.
Disable tests and other not needed parts
Add includes for QCA
Fix build errors on sailfish
Get core/ to build on sailfish
Get interfaces/ to build on sailfish
Build daemon on sailfish
On sailfish, dont install the kcm file
Start port plugin to sailfish
Fixup installed files
Add sfos app
Hack declarative plugin to give a public interface
Build sfos app
Compile declarativeplugin into the sfos app for now
Redefine qAsConst for qt 5.6
Packaging fixes
Use official icon
Package .desktop
Reviewers: #kde_connect, apol, nicolasfella, albertvaka
Reviewed By: #kde_connect, apol, nicolasfella, albertvaka
Subscribers: kdeconnect, andyholmes, albertvaka, kossebau, mtijink, vonreth, apol, #kde_connect, nicolasfella
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D10703
Summary:
Add a helper function to the daemon interface, which must be subclassed
by the implementations, which creates a simple notification.
For more complex needs, involving interacting with the notification, it
will still be nescessary to use KNotification directly, but this allows
for other future implementations to create a simple notification without
ifdef'ing the code.
Reviewers: kdeconnect, apol
Reviewed By: apol
Subscribers: kdeconnect
Differential Revision: https://phabricator.kde.org/D11104
