The future of Power Management - together with Activities

Steven Sroka sroka.steven at
Tue Oct 4 19:59:35 BST 2011

>On 2 October 2011 19:01, Dario Freddi <drf54321 at> wrote:
> 2011/10/2 Michael Pyne <mpyne at>:
>> 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.
> Although I generally agree with this mindset, I urge you to notice we
> are in a very special case here. We are not talking about a cool
> feature in an application, but instead about an important part of the
> system the user should not even have to configure - tomorrow I´ll post
> the first version of the activity-based UI I am thinking of and my
> masterplan will be even more clear. So I think we should focus on
> covering the most widely used use cases, or better: only the ones
> which technically make sense, as it´s very likely a different use case
> could be a consequence of a misunderstanding or a misuse of the
> features additionally provided - as this thread shows, this is clearly
> the issue with profiles.
>>> 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).
> Yes, that´s a very good summary.
>> 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.
> Exactly.
>> 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.
> It might as well be that I have been not clear enough in explaining my
> proposal, and if so, I apologize for that and for what came out of it.
> But back to the point, YES, you got it! The point is exactly that the
> average user does not care about profiles at all, and he probably does
> not even know how to/he can change them. Again, when I´ll show you my
> ideas things will be even clearer in this regard.
>> 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. :)
> I know, and I am sorry I had to come to a point where I needed to be
> harsh. You also have to keep in mind I am one of the few guys who does
> the dirty job, and I mostly get flames more than anything. Usually,
> the gratification for a developer is having users saying ¨thanks, your
> app rocks¨: my gratification is usually getting no feedback at all
> because things work as they should. In addition, I get flamed
> everytime I propose a change, because people refuse to accept there
> might be better ways of working, and when it´s implemented and
> working, I get no ¨sorry,in the end you were right¨ or a ¨thanks¨, or
> anything similar for the very rule I stated above.

I would like to thank you Dario and Bjorn for the changes. I'm excited
to use the power manager changes especially coupled with the KWin
optimizations that are being done by the KWin developers :)

There next release of KDE SC should be amazing on laptops, netbooks
and other mobile devices.

> I wish more people kept that in mind, and understand why I can be more
> sensible about some behaviors and ways of facing informal discussion
> on technical topics than many others. As I said in a previous mail, I
> have to deal with such crap all the time from random users, and I
> don´t want this to happen when I talk to fellow developers as well. So
> I am sorry and I deeply apologize if I can get easily angry when
> discussions start going down these kind of slopes, but at least try
> and show some understanding from the other side as well.
>> Regards,
>>  - Michael Pyne

More information about the kde-core-devel mailing list