The future of Power Management - together with Activities

[Michael Pyne]

On Sunday, October 02, 2011 19:52:09 Dario Freddi wrote:
> On Sunday 02 October 2011 19:35:15 Michael Pyne wrote:
> > 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".

I worry about that mentality. Not so much the idea that features shouldn't be 
added without use cases in mind, but the idea that features inadvertently 
present should be removed without "valid use cases". So many software 
applications find use beyond what their developers initially had intended or 
even understood was possible. I don't understand why this should be 
concerning.

> 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?

I'll admit that I've misunderstood much of your proposal, over at least the 
first day this thread was going on. If I'm understanding correctly now, then:

* The ability to change the currently-loaded profile will go away. The 
currently-loaded profile will instead be based on the combination of <current 
Activity> and <condition of battery/AC>.

* It will instead be possible to inhibit all power management functions (e.g. 
for presentation mode).

* It will always be possible to change the screen brightness (most important 
parameter for power savings).

* And, it will be possible at any time to edit the power management settings 
for the current <Activity/power condition>. (This, btw, is the only thing I 
found unclear).

If this is true then there is not a large concern, the user is still more or 
less easily able to do what he/she was able to do before (independent of "use 
case analysis"...) and in fact has an easier task if they use Activities.

So to answer your question, I couldn't care less about how easy it is to 
create profiles. I've never created profiles, I've always just changed 
whatever setting was wrong at the time or used one of the default profiles 
that was "close enough". But the fact that you asked the question shows that 
we were not communicating effectively, because you thought I cared at all 
about that, and I thought you seriously intended to prevent changing the 
profile *settings* without going through a new Activity first.

Please let me know where I'm wrong on that. And please keep in mind that I 
have been, as far as I know, polite and at least putting in a good-faith 
effort to fully understand the proposal and its impact, and it would be nice 
to have that assumption borne in mind in replies to myself. :)

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111002/86d88114/attachment.sig>