The future of Power Management - together with Activities

Oswald Buddenhagen ossi at
Thu Oct 6 20:41:18 BST 2011

On Sat, Oct 01, 2011 at 08:33:06PM +0300, Andras Mantia wrote:
>  What I can say that I use the selection combo between the different 
> power management schemes from time to time, as I can do the same thing 
> (e.g developing so not anything like now I develop and then switch to 
> mail reading/watching a movie), but depending on the battery status and 
> the known time until I can recharge the battery, I can tweak the power 
> management setting. There is no way any software could guess when will I 
> be able to recharge my battery. 
after reading the whole thread (what a waste of time ...), i still
haven't seen a credible response to this.
irrespective of what actually does save power, the decision whether it
is worth to save extra power is not 1:1 coupled to being on AC, so
hardwiring the power profile to the AC status without an override is
just wrong.
activities are not a solution, because the availability of power is
(technically) orthogonal to the, uhm, activities.
tinkering with the settings of the current power profile is no solution
either, because it is way too cumbersome and just backwards.

the second interesting subthread is what is and should be actually
influenced by a power manager.
the fact that some not time critical system activities (e.g., nepomuk
indexing) are not bound to the power profile but directly to the AC
status is not really an argument against using power profiles, but could
be considered a bug instead.
hdd spindown timeout and write spinup delay arguably should be part of
the profile, too. there are probably more settings for trading potential
power saving for convenience/safety (the dpms settings fall into that
category, after all).

anyway, i think there is a simple solution for the profile switching:
make it possible to override solid's idea of AC status, and expose it in
the applet ("auto" and "plugged". forcing "battery" seems pointless to

More information about the kde-core-devel mailing list