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):
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:
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 🙂