GitLab

allowed by Bison special exception

m_rechargabel -> m_rechargeable in the battery code of the Windows backend.

REVIEW: 118935

Reviewed by Kai Uwe.

This adds the following functionality to Solid::Battery:

- timeToFull and timeToEmpty (at the moment provided by PowerDevil but for all batteries combined, this patch does it individually for each)
- rename isPlugged to isPresent (as plugged always confused me - it has nothing to do with whether AC is plugged in but if the battery is "present in its bay", it's also the name of the UPower iface)
- FullyCharged battery state, we cannot rely on the battery being 100%, and since the info is provided by UPower (not on HAL), why not use it
- RecallVendor/RecallUrl when a battery has been recalled by the vendor, currently provided/handled by PowerDevil
- Serial number of the battery

Sorry for the hard to read patch but I also re-ordered some methods to have the order in all implementations and headers the same.

REVIEW: 117339

This job allows to set the system into a new state, for example
put the system to Sleep, Hibernate or suspend the Screen.

actual, expected instead of expected, actual.

StatesJob will return the supported device states.

Instead of having different list of Inhibitions and States we will
instead have a list of supported States by the device that the developer
will be able to set the device to, or to prevent it to happen
(inhibition).

As rightn ow we only support the ones supported in Linux/Freedesktop,
but in the future we will add things only found (at the moment) in
android.

By popular demand the Inhibition object has now some logic into it.

The idea is that InhibitionJob will return an Inhibition object that
is already started (so the inhibition is in place), and you can keep
that object to start/stop the inhibition depending on the app state.

For example:
The moment a video starts playing in our VideoPlayer we Call
InhibitionJob, hence creating an Inhibition object. If the video
is paused, then we stop the inhibition. When the video is playing
again we start the inhibition.

Based on the feedback of the 3 applications that have moved to this api
rename InhibitionHolder to Inhibition.

So far 3 different projects have ported to this api and all of them have
concluded that InhibitionJob is a better name for this class.

Their orders, my commands.

Export the classes so that it can be imported from a 3rd party user.
So far, tests are using the Solid_static executable that exports everything
and doesn't need this.

CCMAIL: afiestas@kde.org

Api should be ready for review, implementation still not finished since
the inhibition data is not being passed to the backends.

Short example of api:
AddInhibitionJob *job = Power::inhibit(Power::Sleep, "Inhibiting sleep);
job->exec();

InhibitionHolder *inhibition = job->inhibition();

//release inhibition
delete inhibition;

There are applications whos live spawn requires them to always be
aware of the power system. A good example of it is Baloo that since
the moment it is executed it needs to be aware of whether the AC is
on or not.

On the other hand, applications like Muon (software installer) they
only need to do power related stuff when they are actually modifying
software (installing, uninstalling, updating).

So, for Baloo we offer a singlethon with QGlobalStatic which is
pretty much memory free.

For Muon we offer our constructor so they can manage the memory
as they please.

Basically we are turning Power into a Object/singlethon and using
it to forward the signals comming from the backends.

This class contains at the moment a static per job we have, this adds a
few interesting things:
-A developer can know what we support by looking at 1 class.
-It adds room for adding an object that will have signals.
-It makes Solid/Power closer to other api in frameworks.

As noticed by ervin nobody should be able to call this method so it
shouldn't be public. It can't be private though since it has to be
re-implemented by classes inhering from Job, so protected it is.