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
Summary: KDE Connect, now with correct naming!
Test Plan: It still builds.
Reviewers: #kde_connect, apol, nicolasfella
Reviewed By: #kde_connect, apol, nicolasfella
Subscribers: nicolasfella
Differential Revision: https://phabricator.kde.org/D11036
Summary:
Change all member variables to the form m_fooBar because it is the preferred form in Qt (it was half and half between this and mFooBar, and a minority didn't have anything).
Place all references and pointers on the side of the type since it is the majority.
Basically:
- mFoo -> m_foo
- foo -> m_foo (if it is a member variable)
- Type &ref -> Type& ref
- Type *ptr -> Type* ptr
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, nicolasfella, albertvaka
Subscribers: albertvaka, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D7312
Makes it possible to specify the different properties sent at once,
rather than one by one as we used to do.
Also port whenever possible to the initializer-list syntax.
REVIEW: 128269
Uses KPluginLoader+KPluginMetadata instead.
Describes plugins in json instead of desktop files. These desktop files are
then embedded into the .so file. All the plugins will be in a kdeconnect/
directory, and those will be the ones to look for.
Note it doesn't drop the KService dependency as KIOCore is a KDE Connect
dependency as well.
REVIEW: 123042
Use iconName instead of sending a fixed-size pixmap around, fix wording and use title
capitalization, more meaningful names in notifyrc, QStringLiteral and new style connect.
REVIEW: 122121
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.
The parent of the QDbusAdaptor has to be a Device, and now it was a
KdeConnectPlugin for the Notifications plugin.
Instead of passing the parent (that is actually a Device) to the
QDbusAdaptor as we were doing in the Battery plugin, I preferred to get the
actual Device from the KdeConnectPlugin, even though it needs a const_cast.
Ported using KDELibs4Support, for a smaller delta, so we can keep
developing on master until we decide not to.
At the moment, it builds and installs but tests don't pass because
of a QCA2 initialization problem I didn't manage to debug yet.
CCMAIL: kdeconnect@kde.org
