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