The future of PowerDevil (and of power management)
Long time no see, again a post on PowerDevil.
PowerDevil has proven to be quite a solid software, and I’m both proud and happy about it: the 4.2->4.3 transition has happened almost with no maintainance (apart from a critical bugfix from Jacopo, thanks!). The proportion of bugs affecting it regard 20% up/downstream problems, 25% “please implement the feature x” and 15% “oh, the GUI sucks and looks confusing” (yeah, percentages are not accurate, I can tell)
The problem is that PowerDevil GUI does suck, big time, because it’s way too cluttered. However, I can’t add cool and nice features without cluttering it even more. Result, there has to be something wrong. The topic came back today by chance in a short conversation with Martin, and while I was eating, suddenly (and by chance, I was not even thinking about it) I got struck by an idea.
Let’s start knowing that Power Management is something that is very much linked to the hardware, and the average user should have a minor part in configuring/dealing with it.
Today, power management systems are based on profiles, more or less configurable. They offer the user access to a set of things to configure, and that’s it. There are some problems, though.
- The options are limited. Some features will still be missing
- The options can’t be expanded: code gets fat, GUI gets unusable
- Everyone loses on the long run: developers have a dirty code base, users have limited possibilities and/or an unusable GUI, distribution don’t have much flexibility in providing custom and effective settings, hardware vendors even less.
To me, this means one thing: the current profile concept fails. That’s why I thought about an alternative: putting an additional layer of abstraction: let’s call it “Actions”.
Actions are containers of, well, actions such as setting CPU scaling, brightness, and anything you can configure with PowerDevil right now. They come in form of plugins (KPlugin ftw!), so that you can create custom Actions (mind the capital letter) by defining your very own set of actions. But let’s make an example, to make things clearer.
You create a new Action, name it “Set Powersaving mode”. In it, you define (using the available plugins), that the scaling should be ondemand, the brightness 10%, the power scheme “powersaving”. That’s it. In the profile chooser, you now have a similar situation: a single page that has some per-event based fields: for example, “When PC is idle for more than 15 minutes, do”. Now what do you do? Just set an Action, in this case “Set Powersaving Mode”.
Everyone wins. Still can’t see why? I’ll tell you:
- Average users: they have to do almost no configuration, and they have it in a very readable form (as Actions can have human readable names, such as “Set Powersaving mode”), and with the best combination in the Actions, that were defined by KDE team, or by the Distro (better), or by the hardware manifacturer (even better)
- Power user: you finally can do the f**k you want with no limits, and I think that’s enough. And the GUI would be damn clean.
- Distributions: you have a way to define your very own actions based on your specific configuration, in a truly easy way, providing your users the best defaults possible
- Hardware vendors, and netbook vendors, I’m mainly looking at you: suppose your new motherboard has a “WOWSAVEALOTOFPOWER” feature, that can be used only on your motherboard by calling some weird functions. Pretty fine. Go ahead, and write 100 line of code to add a new plugin to PowerDevil’s Action system, to let Powerdevil handle it. Netbook vendors shipping KDE can also include it in their default Actions, to give their users the very best.
Looks cool? Obviously, we still miss one step, the configuration of events. I mean, leaving “When the pc is idle for … minutes” gets you limited and hardcoded. So simple, let’s apply the same concept to events too. A profile configuration GUI would look like this (squallid, more conceptual than anything else mockup):
That’s the concept. Slick, huh?
Well, even if it’s a fast and quick mockup, I think you will agree with me that it already looks much more polished than the current one 😀 And as you can see, adding a new event is very, very easy and human-readable. I also have a mockup for the Action editor:
Even more slick!
That’s it, the Events one would be analogue to the action one. As you can see, both GUIs need some love, but have a very simple and powerful concept behind. What’s more, is that this way we are getting even closer to Power Management integration in the system: all application would be able to define their own events/actions, allowing, for example, to stop your music when you enter deep powersaving mode, or anything you can think of.
Now, I’ve been eloquent enough, and now I would like to grab opinion and ideas. Do you like it? Would you like to see it in 4.4? Do you think it’s a major improvement and/or sucks? Let’s gather some ideas so that I know where to work on 🙂
A Quiet Place 
love this idea, especially the advantage for hardware vendors! Would like to see this in 4.4!
Wouldn’t it be nice if there was some sort of general event/action handling in KDE? This way, any event in any application can trigger any action (or event) in any other application.
(Looks a lot like signal/slots in Qt)
“Wouldn’t it be nice if there was some sort of general event/action handling in KDE? This way, any event in any application can trigger any action (or event) in any other application.
(Looks a lot like signal/slots in Qt)”
I started such a thingy once but everyone I tried to explain the idea to, didn’t really share my excitement about it.
I think I’ll start again.. 🙂
It even looks quite like dario’s mockups.. :
I basically have a “caller” group where many different events can be added (like a dbus signal, a time event..) and a “action” group where resulting actions to this “set” can be added. Like a commandline, a dbus slot, predefined commands.
The dbus handling is still very basic but i’m able to shutdown my computer “on dragonplayer finishing it’s movie or in 45 minutes”. I already use it a lot even though it’s quite far from any releasable state 😉
And for now it’s qt only.
> Wouldn’t it be nice if there was some sort of general event/action handling in KDE?
> This way, any event in any application can trigger any action (or event) in any other application.
What problem does that try to solve?
@Diederik
For example, say that you start a slideshow in Gwenview. Gwenview emits “slideshow” and PowerDevil reacts by setting the screen brightness to 100% and disabling the screensaver and monitor sleep mode.
I think it is an absolutely brilliant idea.
I like it. You won’t know for certain until you try this out with a variety of users but intuitively I expect the concept of an ‘action’ would be easier to grasp than a profile.
Some suggestions:
* For the ‘Set Brightness Level’ action, a spin-box is not the most friendly widget to use because it doesn’t give any idea of what the range of possible values is and what they mean. A slider from ‘Brightest’ to ‘Dimmest’ would be better.
* Some text tweaks are needed. As I said before, I think you’ll need to find some actual users to find out what they do and do not understand but once example is that I don’t think it is obvious that the ‘put the laptop to sleep’ functionality is found under the ‘Set PC state’ option.
I like it so far, it’s a great concept, lets see how it evolves :]
all thumbs up, looks like its the best of both worlds.
Great idea!
I like that idea very much.
And powerdevil in general. Thanks for the work!
Cool!
Really cool idea!
@job: Me too! If that would be implemented, it would be absolutely awesome, I miss something like this badly, nearly every day there’s a situation where it would be damn useful.
How do you plan to deal with conflicting events like:
* From 2PM to 6PM: set Powersaving Mode
* From 4PM to 11PM: set Full power Mode
?
What’s happening, for example, from2PM to 6PM that triggers your need to be in powersaving mode? Obviously it cannot be only “time”, right?
If you constrain events to be triggered on a *points of time* basis, as opposed to *periods of time* this won’t be a problem.
This sounds like a very sound approach/model. It would be nice to be able to tie conditions to events, for instance when “the PC has been idle for 10 minutes” and “Amarok is not playing music” so that if one puts on some music the PC will keep on playing and not suddenly be shut down.
That sounds great. I could use this for networking too. Like “If I connect to an unencrypted network, use VPN”, “If I connect to this network, open this webpage” (for login)”, “If I connect to this network, minimise network traffic” (because it is expensive)”. “If I connect to this network, start this work environement”. So it would be good, if you design it in away that other parts of KDE can use it too.
Sounds interesting. However, isn’t what you’re doing basically defining the transitions between the states of a state machine (events and actions), rather than defining the states themselves (conditions and profiles)? Couldn’t this end up getting messy, by having whatever things the previous actions did still be around to affect the state all the further actions have to interact with? For example, to go with the example in the first screenshot, wouldn’t you need to have a “PC is no longer idle” event coupled to an “Unset Powersaving Mode” action, otherwise it’ll stay in powersave mode forever once it’s been idle for 10 minutes at any point? I suspect you’d eventually just end up reimplementing the functionality of profiles, only in a more verbose and error-prone way (for example, the Set Powersaving Mode action using some plugin the Unset Powersaving Mode action doesn’t know about and doesn’t know to unset).
Couldn’t the whole plugins concept be integrated with the existing profiles mechanism somehow? Basically, I think, you’d just need to have the plugins define a property and the states it can be in (“WOWSAVEALOTOFPOWER feature is disabled/enabled”) along with the code to move between those states (an implementation detail), and then let the user specify what states the various plugin-defined properties should be in in the various profiles.
Along with user-defined conditions (for example, “computer has been idle for 10 minutes”) rather than events, of course. If you wanted to do away with profiles, you could just have the conditions correspond directly to a list of properties and the states they should be in; the main point is that the concept should be “while this condition is true, the following properties should be in the following states” rather than “when this event happens, do that action”, because you’d just end up having “X condition starts being true” and “X condition stops being true” as your events and “set property on” and “set property off” as your actions, and it’ll be the same thing only messier.
@I-love-it: Thanks! 😀
@job/seezer, yeah, the idea might be cool, but in this case is meant for a very specific scope 🙂
@Robert: Well, it’s a bit early to talk about GUI Implementation, those are 20 seconds worth of mockup each ^^ I’m just asking for guidance on the concept
@RS/illissius: Nice point you two both make. Let’s try to districate it.
First of all, I’m not moving away from profiles, just redefining the concept of them. Profiles will be just a “script” with a series of events->actions.
Race conditions: let’s try to get a layer: we have default, that is the bottom layer. Each triggered event, gets one layer upper. So let’s say that property X is y by default, z from 2am to 5 am and k from 3 am to 4 am. So, at 2 am the property would be z, at 3 am would be k, and 4 am back to z. The last triggered event has priority, and then we fall back on each layer.
To answer illissius concern, event framework would have a “triggered” and “released” state, for events that actually have a duration (such as PC being idle, from hour to hour as before, etc), that set/unset what they need to modify in the logic of layers I explained before. And then, we would have some “one shot” events that trigger an event without releasing it (such as pressing a button), where this problem does not persist. Obviously, you *WON’T* have to manually define this by hand, otherwise the whole concept would be screwed. If all of this gets true, the functionality of PowerDevil as an application would be just the one to “manage” layers, everything else happens in the plugins. What do you think about this?
@hlovdal: nice! This could be an advanced feature for power user
Thanks to everyone for your feedback 🙂
You need to add a feature that shows what the amount of power saving any particular item or groups of items will achieve (even if approximated somehow). And the savings have to be in units average people will understand.
For example: Old CRT monitor off = 90 watts, CPU box in idled mode = 27 watts. Spin down hdd = 7 watts. Convert that to minutes of battery life increases or have an option for the user to input ‘cost of local electricity’ or greenhouse gases and give an annual cost marker…
.X..display off in 10 minutes = 90watts or $50/yr or +2hrs of battery life
.X..throttle cpu = 27watts; $25/yr; +3hrs battery; 3 tons of C02 saved.
.0..spin down hdd = 7watts or $0.50/yr or +11minutes of battery life
You can have a long table-like list of all the features and have a counter or bar-chart on the side that grows every time you click a radio button to turn that feature on. It becomes a game. How tall can I make that bar chart in dollars and minutes of battery life the more buttons I click on. Rank the chart from the hungriest items to the least hungry so that if a user does get tired going down the list they can at least practice the 80/20 rule.
Some simplification can help: That ranked list could be broken into sections like “aggressive display” with the typical sub-questions that can be micromanaged like 5 minute or 10 minute control but the main head could be selected to choose all aggressive display. Maybe they want screaming CPU with no power saving but a monitor that’s almost off (like running a headless server).
You still might have some fun with the metrics… Number of equivalent hours on the treadmill or exercise bike or Big Mac calories per year.
The key is that people are given a method to gage how much power saving is important to them and to quickly get most of the way there.
I really like this idea.
sometimes the UI that works for me doesn’t work for most other people.
there’s just one thing that worries me… it reminds me of my own idea for configuring mouse plugins for my soc project, and *that* UI mockup got shot down for being a “space-shuttle interface in a car” or something along those lines.
I love the fact that, unlike the current profiles situation, you don’t have to define any more parameters than are necessary for each action. Assuming a reasonable set of default events and actions, I think this is a brilliant combination of power and simplicity. Certainly a vast improvement and I would love to see it implemented.
My company has launched a product called Powerwise in the US which provides PC Power Management for the Windows platform. I am trying to get the word out. If anybody wants to evaluate it for their company with no commitment or money required up front please contact me. Our product implements a lot of the items discussed above and may be of interest. My web site is http://www.squeezetech.com, just contact from there and I can let you download the code and see what you think.
We went through the same event / system state adventure a while back.
[…] The future of PowerDevil (and of power management) Long time no see, again a post on PowerDevil. PowerDevil has proven to be quite a solid software, and I’m both […] […]
Top Posts « WordPress.com said this on 4 May, 2009 at 2:39 am |
[…] The future of PowerDevil (and of power management) Now, I’ve been eloquent enough, and now I would like to grab opinion and ideas. Do you like it? Would you like to see it in 4.4? Do you think it’s a major improvement and/or sucks? Let’s gather some ideas so that I know where to work on […]
Links 03/05/2009: Fedora Classroom Today, Palm to Enter Sub-notebooks? | Boycott Novell said this on 4 May, 2009 at 3:10 am |
You might also consider simplifying the current interface so that you regain a bit of space to add new stuff. (Only 15% for “user interface is confusing” issues is lower than I would have expected.) Here’s some suggestions (coming from the 4.2 version that I’m currently running):
* General settings, stab 1:
If you look at it, “Profiles Assignment” and “Advanced Battery Settings” are really the same thing. Imagine a layout like this:
– On AC power | (spacer) | (profile combobox)
– On battery | (spacer) | (profile combobox)
– On low battery | (percentage spinbox) | (profile combobox)
– Critical battery level | (percentage spinbox) | (actions combobox)
That would, for instance, get rid of the split between “Settings and profiles” and “Advanced Battery Settings”, and I claim it’s more usable still. Also note that I dropped the “warning” battery level… really, no one actually needs 3 different on-battery states, “normal” battery and “low” battery should really be enough. Which also has the advantage that you can drop one profile, so one set of configuration values doesn’t have to be configured at all. Cool.
* General settings, stab 2:
The user can already enable notifications in the “Configure Notifications” dialog that is accessible through the button. So again, without any loss in functionality, you could just drop both the “Enable notifications” and “Enable warning notifications” checkboxes, and let the user configure it by opening the dialog and selecting the configurations on a case-by-case basis. The list of events is reasonably small, and most users won’t feel the need to change the default notifications anyways, so why clutter the interface with redundant options.
Personally, I’d also drop the “Before doing a suspend action, wait N seconds” dude – seriously, who is going to change that? (and why would they want to do it? i can see no use case for this option being disabled or changed.)
* Profiles, introduction and short rant (sorry, I have to):
When Sebas countered Matthew Garrett’s accusations, he dismissed practically all of the suggestions saying they’re getting implemented anyways (or similar). I must say when I saw the final 4.2 version I was really disappointed to see all of Garrett’s points being totally valid and unaddressed. So if you want to improve user experience, maybe you should focus on those points first.
* Profiles, stab 1:
The “When Laptop Lid Closed”, “When Power Button Pressed” and “When Sleep Button Pressed” options should be global. It’s not only tiring that I have to set these five times if I want to change them, but if different settings are actually used then that’s also confusing to the user: At which of four battery levels does it invoke which action? Try to remember all possible combinations, and I’ll tell you it’s not a good idea to let your users do that. Less complexity here actually equals more usage of the lid and buttons, because people can rely on a single action being executed (and thus, they feel confident enough to invoke the action).
* Profiles, stab 2:
I know that it might take a tiny amount of flexibility away, but if you hardcode the set of available profiles then you can put them in the iconview on the left, replacing the “Edit profiles” tab with the direct four profiles (AC Power, Battery, Low Battery, Presentation). That way, stuff like the energy star logo or some description/combobox combinations might actually fit into the dialog at standard sizes.
I didn’t consider this in my “General settings, stab 1” suggestions, so let’s rework the layout there once more:
– Low battery level: (percentage spinbox)
– Critical battery level: (percentage spinbox)
– On critical battery level: (actions combobox)
Even simpler, still with no loss in functionality (apart from the hardcoded set of profiles, of course).
* Profiles, stab 3:
As Matthew Garrett stated, certain settings don’t belong in there as they’re not really related to power management and battery runtime. “Turn off the following CPUs” and the cpufreq governor are unnecessary if not misleading, I don’t quite get why these really need to be exposed this prominently. Power users who actually know the real implications could easily set this by means of the run-script-on-loading-profile option. Likewise, (also as per Garrett’s remark,) KWin compositing doesn’t really belong in power management settings either.
All in all, you should now be able to fold the “CPU and System” tab into “Actions”, and if you made the profiles into iconview KCMs then the layout allows for real tabs instead of the ToolWidget pseudo-tabs. usability++ :-]
* Profiles, stab 4:
The Presentation profile needs to vanish, too. It shouldn’t be a separate profile but a set of overrides that modify the current profile. Essentially, all it needs to do is a) disable the laptop lid and system-idle-for-N-minutes actions, b) disable display power management, and c) disable the lock-screen functionality.
Also, last time I checked, Dragon Player did not cause a switch to the Presentation profile, and brings up those obnoxious screen locks in the middle of watching movies. I wonder if there is a possibility to make it work automatically with cross-platform players like VLC too.
If you can’t rely on the Presentation mode being enabled reliably, I suggest making “Presentation” into a toggle pushbutton for the plasmoid popup, right next to the profile selection combobox (without text, only showing the “presentation” icon that’s also used in Okular or Digikam). Or, if you decide to implement my suggestion of hardcoding the set of profiles, that toggle button might just replace the Profile selection altogether (as the profile is anyways selected by the battery state).
* One more point:
The What’s This help text screams “PowerDevil” in big letters, and “Let PowerDevil manage screen powersaving” also contains the name. You already made some adaptations to not show the daemon name in all places, but it’s still left in some prominent ones. That’s not only offending to the one guy from the Dot who fears the devil, but also requires the common user to learn about implementation issues that shouldn’t be necessary to know. I jus wanted to suggest replacing the display power management option with “KDE power management” instead of “PowerDevil”, but now that I think of it, that option is already present in the profile settings. So why don’t just get rid of it and configure it there.
— end of suggestions
I hope you can make something out of these points. Please note that I’m not at all pursuing the GNOME approach of removing useful settings. But in its current state, PowerDevil requires a significant effort for the common user to get simple settings set up properly, only to make a few features possible that won’t be used by virtually anybody. Please try to get the interface up to speed, I’ll promise you it’ll be easier to add other useful options afterwards… and really, making the current UI usable is more important right now than adding new stuff to it. Hopefully you’ll agree with that :]
I’m confused. I think the profile model works well if set up properly. On a laptop, the computer is either plugged into an electrical socket or not, which is the primary determiner of which power settings to use. When I’m at school I’m on battery power with the wireless antenna turned on (of course this repeats itself if I’m at a cybercafe). So I have desktop effects turned off, cpuscaling on, lower time until suspend to RAM kicks in, etc. I typically use the computer until the battery’s too weak to keep the system powered, and it goes into suspend to disk -hopefully I’ve remembered to copy whatever files I need to a flash drive or my network share before it does so! When I’m at home I’m plugged into the outlet and have a network cable plugged in. None of those previous power conserving needs are still around. So all I need are two saved sets of settings -profiles- On the Road, and At Home. I don’t see how the UI in this post would help in that kind of work flow.
I would worry that this approach might actually be more confusing. I think this would be a prime candidate for a proper usability study.
As much as I am naturally sceptical about the amount of trust developers put in these studies which basically boil down to observing a handful of people for a few hours, I have to admit they do seem actually pretty effective, particularly for cases like this.
I would worry that this approach might actually be more confusing. I think this would be a prime candidate for a proper usability study.
As much as I am naturally sceptical about the amount of trust developers put in these studies which basically boil down to observing a handful of people for a few hours, I have to admit they do seem actually pretty effective, particularly for cases like this.
very very thank you
a place totals up the data the knowledge is a lot of techinque main point data techinque the knowledge is all-round goods is modern
[…] Preventing Powerdevil from changing brightness Thanks for the links! There is also this old blog post about the future of power devil being event driven rather than profile oriented, which seems to be […]
Preventing Powerdevil from changing brightness - openSUSE Forums said this on 13 April, 2010 at 10:28 am |
[…] First of all, I’d like to implement at least a good part of the features I described in this previous post; secondly, PowerDevil’s code is starting to show its age and my inexperience at the time of […]
Various updates and stuff « A Quiet Place said this on 15 April, 2010 at 7:21 am |
Since enabling Powerdevil i realise very agressive HDD Powermanagment after login to KDE. Spindown is taking place after 30 sec. Idle. Can U make this Behaviour an selectable Option in Powerdevil and defaulting to 10 Minutes?
cu
正規代理店
Shopper Approved is based on the powerful concept called ‘social
proof’, which states that:
When a potential customer goes online to buy a product or
service, they actually want and actively
look for reassurance that they’re making the right decision. And the way they
get that assurance is
from other customers’ ratings, feedback, and reviews.
This is why statistically, 77% of online shoppers turn to consumer reviews before
they decide to buy!
There’s a reason why Amazon, eBay, Sears, and pretty much every other major ecommerce site have customer
ratings and reviews integrated into their website. It’s because
online reviews have been proven to increase
conversion, increase average transaction amounts, improve customer
satisfaction, and even lower product
returns!
Check Out The Link In Signature