2013-07-26 15:21:19 +01:00
|
|
|
/**
|
2020-08-17 10:48:10 +01:00
|
|
|
* SPDX-FileCopyrightText: 2013 Albert Vaca <albertvaka@gmail.com>
|
2013-07-26 15:21:19 +01:00
|
|
|
*
|
2020-08-17 10:48:10 +01:00
|
|
|
* SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
|
2013-07-26 15:21:19 +01:00
|
|
|
*/
|
|
|
|
|
2013-08-13 23:03:46 +01:00
|
|
|
#include "batteryplugin.h"
|
2013-07-26 15:21:19 +01:00
|
|
|
|
2013-09-04 20:19:02 +01:00
|
|
|
#include <KLocalizedString>
|
2014-09-22 01:37:10 +01:00
|
|
|
#include <KPluginFactory>
|
2013-07-26 15:21:19 +01:00
|
|
|
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
#include <Solid/Battery>
|
2022-09-10 22:23:52 +01:00
|
|
|
#include <Solid/Device>
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
#include <Solid/Predicate>
|
|
|
|
|
2018-03-18 11:42:15 +00:00
|
|
|
#include <core/daemon.h>
|
|
|
|
|
2020-05-26 17:55:47 +01:00
|
|
|
#include "plugin_battery_debug.h"
|
2013-07-26 15:21:19 +01:00
|
|
|
|
2019-06-12 21:16:54 +01:00
|
|
|
K_PLUGIN_CLASS_WITH_JSON(BatteryPlugin, "kdeconnect_battery.json")
|
2013-07-28 21:00:45 +01:00
|
|
|
|
2023-07-17 13:14:11 +01:00
|
|
|
const auto batteryDevice = Solid::DeviceInterface::Type::Battery;
|
|
|
|
const auto primary = Solid::Battery::BatteryType::PrimaryBattery;
|
|
|
|
|
2022-09-10 22:23:52 +01:00
|
|
|
BatteryPlugin::BatteryPlugin(QObject *parent, const QVariantList &args)
|
2013-08-13 23:03:46 +01:00
|
|
|
: KdeConnectPlugin(parent, args)
|
|
|
|
{
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
QList<Solid::Device> batteries = Solid::Device::listFromQuery(Solid::Predicate(batteryDevice, QStringLiteral("type"), primary));
|
|
|
|
|
|
|
|
if (batteries.isEmpty()) {
|
|
|
|
qCWarning(KDECONNECT_PLUGIN_BATTERY) << "No Primary Battery detected on this system. This may be a bug.";
|
|
|
|
QList<Solid::Device> allBatteries = Solid::Device::listFromType(batteryDevice);
|
|
|
|
qCWarning(KDECONNECT_PLUGIN_BATTERY) << "Total quantity of batteries found: " << allBatteries.size();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-08-22 16:28:35 +01:00
|
|
|
// Ok, there's at least one. Let's assume it will remain attached (for most laptops
|
|
|
|
// and desktops, this is a safe assumption).
|
2022-09-10 22:23:52 +01:00
|
|
|
const Solid::Battery *chosen = batteries.first().as<Solid::Battery>();
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
|
2020-08-22 21:37:18 +01:00
|
|
|
connect(chosen, &Solid::Battery::chargeStateChanged, this, &BatteryPlugin::slotChargeChanged);
|
|
|
|
connect(chosen, &Solid::Battery::chargePercentChanged, this, &BatteryPlugin::slotChargeChanged);
|
2023-07-17 13:14:11 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int BatteryPlugin::charge() const
|
|
|
|
{
|
|
|
|
return m_charge;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool BatteryPlugin::isCharging() const
|
|
|
|
{
|
|
|
|
return m_isCharging;
|
|
|
|
}
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
|
2023-07-17 13:14:11 +01:00
|
|
|
void BatteryPlugin::connected()
|
|
|
|
{
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
// Explicitly send the current charge
|
2020-08-22 21:37:18 +01:00
|
|
|
slotChargeChanged();
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
}
|
|
|
|
|
2020-08-22 21:37:18 +01:00
|
|
|
void BatteryPlugin::slotChargeChanged()
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
{
|
2020-08-22 16:28:35 +01:00
|
|
|
// Note: the NetworkPacket sent at the end of this method can reflect MULTIPLE batteries.
|
|
|
|
// We average the total charge against the total number of batteries, which in practice
|
|
|
|
// seems to work out ok.
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
bool isAnyBatteryCharging = false;
|
|
|
|
int batteryQuantity = 0;
|
|
|
|
int cumulativeCharge = 0;
|
|
|
|
|
|
|
|
QList<Solid::Device> batteries = Solid::Device::listFromQuery(Solid::Predicate(batteryDevice, QStringLiteral("type"), primary));
|
|
|
|
|
|
|
|
for (auto device : batteries) {
|
2022-09-10 22:23:52 +01:00
|
|
|
const Solid::Battery *battery = device.as<Solid::Battery>();
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
|
2020-08-22 16:28:35 +01:00
|
|
|
// Don't look at batteries that can be easily detached
|
|
|
|
if (battery->isPowerSupply()) {
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
batteryQuantity++;
|
|
|
|
cumulativeCharge += battery->chargePercent();
|
|
|
|
if (battery->chargeState() == Solid::Battery::ChargeState::Charging) {
|
|
|
|
isAnyBatteryCharging = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (batteryQuantity == 0) {
|
|
|
|
qCWarning(KDECONNECT_PLUGIN_BATTERY) << "Primary Battery seems to have been removed. Suspending packets until it is reconnected.";
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Load a new Battery object to represent the first device in the list
|
2022-09-10 22:23:52 +01:00
|
|
|
Solid::Battery *chosen = batteries.first().as<Solid::Battery>();
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
|
|
|
|
// Prepare an outgoing network packet
|
|
|
|
NetworkPacket status(PACKET_TYPE_BATTERY, {{}});
|
|
|
|
status.set(QStringLiteral("isCharging"), isAnyBatteryCharging);
|
2020-12-02 22:22:05 +00:00
|
|
|
const int charge = cumulativeCharge / batteryQuantity;
|
|
|
|
status.set(QStringLiteral("currentCharge"), charge);
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
// FIXME: In future, we should consider sending an array of battery objects
|
|
|
|
status.set(QStringLiteral("batteryQuantity"), batteryQuantity);
|
2020-12-02 22:22:05 +00:00
|
|
|
// We consider the primary battery to be low if it's below 15%
|
|
|
|
if (charge <= 15 && chosen->chargeState() == Solid::Battery::ChargeState::Discharging) {
|
Finally, we have support for sending out Battery information.
## 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?
2020-04-13 06:54:11 +01:00
|
|
|
status.set(QStringLiteral("thresholdEvent"), (int)ThresholdBatteryLow);
|
|
|
|
} else {
|
|
|
|
status.set(QStringLiteral("thresholdEvent"), (int)ThresholdNone);
|
|
|
|
}
|
|
|
|
sendPacket(status);
|
2013-07-26 15:21:19 +01:00
|
|
|
}
|
|
|
|
|
2023-07-31 08:25:45 +01:00
|
|
|
void BatteryPlugin::receivePacket(const NetworkPacket &np)
|
2013-08-13 23:03:46 +01:00
|
|
|
{
|
2020-08-22 21:37:18 +01:00
|
|
|
m_isCharging = np.get<bool>(QStringLiteral("isCharging"), false);
|
|
|
|
m_charge = np.get<int>(QStringLiteral("currentCharge"), -1);
|
|
|
|
const int thresholdEvent = np.get<int>(QStringLiteral("thresholdEvent"), (int)ThresholdNone);
|
2013-07-26 15:21:19 +01:00
|
|
|
|
2020-12-13 12:28:23 +00:00
|
|
|
Q_EMIT refreshed(m_isCharging, m_charge);
|
2020-08-22 21:37:18 +01:00
|
|
|
|
|
|
|
if (thresholdEvent == ThresholdBatteryLow && !m_isCharging) {
|
2022-09-10 22:23:52 +01:00
|
|
|
Daemon::instance()->sendSimpleNotification(QStringLiteral("batteryLow"),
|
|
|
|
i18nc("device name: low battery", "%1: Low Battery", device()->name()),
|
|
|
|
i18n("Battery at %1%", m_charge),
|
|
|
|
QStringLiteral("battery-040"));
|
2013-07-26 15:21:19 +01:00
|
|
|
}
|
2020-08-22 21:37:18 +01:00
|
|
|
}
|
2013-07-26 15:21:19 +01:00
|
|
|
|
2020-08-22 21:37:18 +01:00
|
|
|
QString BatteryPlugin::dbusPath() const
|
|
|
|
{
|
2023-08-12 12:26:05 +01:00
|
|
|
return QLatin1String("/modules/kdeconnect/devices/%1/battery").arg(device()->id());
|
2013-07-26 15:21:19 +01:00
|
|
|
}
|
2013-07-28 21:00:45 +01:00
|
|
|
|
2014-06-16 19:02:07 +01:00
|
|
|
#include "batteryplugin.moc"
|
2023-07-26 09:15:11 +01:00
|
|
|
#include "moc_batteryplugin.cpp"
|