The future of Power Management - together with Activities

Dario Freddi drf54321 at gmail.com
Sun Oct 2 18:52:09 BST 2011


On Sunday 02 October 2011 19:35:15 Michael Pyne wrote:
> And look at it from the user perspective. The DE should be smart, but if
> the  user decides that this one time he wants the computer to act as if
> the AC cord were plugged in even though it's not, and even though he
> normally wants something different in the current activity then who are we
> to tell them otherwise?

The point is there is not a valid use case for that. I could also say that the 
user might want to "rm -rf /", and who are we to tell him otherwise. You are 
already, unconsciously, leaving to kernel 80% of proper power management - for 
this reason, as I already explained a gazillion times and I won't repeat 
myself, the only setting the user might want to be temporarily changed is 
brightness - and we're already striving to provide the best experience with 
it.

> 
> And even assuming the user knows how to do this, if they want to change
> power  management options we are saying that they need to duplicate an
> existing activity, change the power management options in that new one,
> and switch to that new activity to do the same thing they were doing
> before. The only one doing something different now is the *computer*. This
> is my point about orthogonality.

But again, it does not make sense. You are failing to provide a valid use case 
for these situations, expect "the user might want to do that". But even 
leaving that aside, I might say: what's the difference between creating a new 
activity and configure it and creating a new profile and configure it, if 
that's the sole purpose of the change?

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111002/6124a756/attachment.sig>


More information about the kde-core-devel mailing list