GitLab

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.

Build upon Solid::Job, this api will offer a set of jobs that will
provide information regarding the power system, some examples:
-AcPluggedJob
-SleepJob
-SleepStatesJob
...

The backends at the moment will be in source and hardcoded since we
don't have time to write a runtime system for it before release. The
classes though are structured in a way that we will allow backends
to be outside our source tree in the future.

To enable this feature compile with:
-DWITH_NEW_POWER_ASYNC_API=On

Since we decided to be a Qt only module we can't depent on kcoreaddons
and re-use kjob, so we are forced to re-invent the wheel.

I have tried to keep the KJob API with two small differences:
-Solid::Job pure virutal is called doStart
	This is because start() will just add to the queue
	the slot doStart so we make sure that start() returns as soon
	as possible.
-Named enum for errors
	This is mostly because it allows us to use the enums from QML.

To enable this class and its test compile with:
-DWITH_NEW_SOLID_JOB=On

/home/scripty/prod/git-unstable/frameworks_solid/src/solid/devices/backends/fakehw/fakedevice_p.h:36: Ignoring definition of undeclared qualified class
/home/scripty/prod/git-unstable/frameworks_solid/src/solid/devices/backends/fakehw/fakedevice_p.h:36: Ignoring definition of undeclared qualified class

Acked by Alex

This allows running nmake test on Windows

It's required by frontend itself, so it needs to be together.
With this change, we fix building of solid users.

This basically makes room for a new folder we will introduce
called power.

It has been brought to my attention that all our source files in
the root of the solid folder are confusing. They where even more
in the kde4 times since they mixed Device inherited classes and some
classes (networking and powermanagement) that had nothing to do with
them.

So, as from this commit we have:
backends/ #Folder where backend code is
ifaces/   #All our interfaces, used on backends
frontend/ #All the classes exported and intended to be used by the user
*	  #Files that are used across folders and other minor stuff

Now we only build it on Unix but not Linux.

We don't build HAL anymore on Linux.

Without UDev in Linux Solid does close to nothing so in order to avoid
packaging mistakes we are going to require UDev.