Summary
Write a power management tool for KDE based on HAL.
(Make this: an universal power management daemon with a KDE GUI. Read comments Elias12 for explanation.)
Rationale
The existing klaptopdaemon uses obsolete technologies and is hard to maintain. The alternative kpowersave duplicates a lot of the power management support included in Ubuntu and exposed through HAL, this would make it very hard to support and it conflicts with Ubuntu packages. So we will write a new frontend to HAL.
Use cases
Maisie wants to suspend her laptop but it doesn't work currently with Kubuntu because klaptopdaemon uses an obsolete method to detect if suspend is possible.
Rhuaridh wants to change the brightness of his laptop but finds that klaptopdaemon has no option to do this.
Boab wants to install kpowersave as the only reliable way to get power management in Kubuntu but finds this uninstalls several Ubuntu power management packages.
Scope
KDE frontend to the properties exposed by HAL. Any laptop specific issues should be solved below HAL.
Design
The daemon will display a systray icon to show the battery level and plugged in status. It will have a tooltip to show more information and a menu which lets you configure or run suspend/hibernate.
The applet check if power management is supported (using HAL) and only run if it is on startup.
The applet will have different settings for when the laptop is powered and battery, when the laptop changes from powered to battery is will change the brightness according to the setting.
It will talk to HAL using libhal. It will listen to HAL signals for battery level. It will query HAL for suspend/hibernate abilities (if one is not available that will be disabled in the GUI), and it will use HAL for starting the suspend and hibernate. It will use hal-system-power-set-power-save for standby mode.
Configuration dialogue:
Tooltip when hovered over applet:
Menu when clicking on applet:
Design drafts can be found at
Code can be found at: http://websvn.kde.org/trunk/playground/base/guidance/powermanager/
Elias12:
- In order to make this thing successful I recommend to choose an approach similar to network-manager: A daemon running in the background and a KDE GUI to talk to it. Why? Because otherwise the point will come where you will throw away all your work and built a GUI for a daemon somebody else has written just like it was with knetworkmanager superseding kde-wireless-config or whatever it's name was.
- The success of network-manager lies in the fact that KDE could use it's advantages eventhough it comes from the gnome community. Another example is dbus which will replace dcop in KDE4. Both nm and dbus could be used by anyone without having to install gnome. This freedom ensures a wide acceptance and potentially attracts a big community driving the development of the project.
- On the contrary dcop did not survive since it was only available when installing all of kdelibs and all dependent packages (QT) as well.
- Therefore I cannot stress enough, if you want to create something with sustained success, something long lasting, then split your project in a daemon and a GUI part. The daemon should exist as a seperate project and consequently as a seperate package with no dependency to KDE. This will make your work available for other desktops as well. Nobody will have to reinvent the wheel. And power management could finally be available even for puristic console users - I never understood why power-management should only be available if you are running a desktop environment anyway. The GUI would either be a subproject of the daemon in a seperate package or some time become an official part of KDE with a dependancy to the daemon package.
LukaRenko:
- I am missing configuration for action to perfom on Close Lid and Sleep/Hibernate/Power key.
- close lid is fixed, key actions are not yet there --sebas
- Since suspend/hibernate is also used by desktop users, we should also think about separating battery stuff (does hal support UPS battery) from suspend/hibernate config.
- It would probably also make sense to separate brightness controls as they are not supported by all laptops (and probably no desktop)
- brightness controls are not shown when HAL doesn't show a brightness device --sebas
Ellen:
DannyKukawka:
Why do you try to develop a new application (I don't believe in a _temporary_ solution!) instead of work on KPowersave as proposed on powersave-devel@forge.novell.com? Why not spend your time to make KPowersave independend from powersave (also if I'm not a fan of powermanagement in HAL!) instead of develop yet an other KDE powermanagement applet? IMO it's a waste of time to develop such a temporary applet and we all (powersave/KPowersave developer, Luka, Michael Biebl and other) already spend enough time to get KPowersave in Kubuntu (I don't like to lose one's labour! ).
- The KPowersave redesign would've taken too long (there's not code yet, after UVF)
Ellen (2006-08-10): Beta Review
- Brightness Slider:
- Battery Critical: What is battery critical? 5%? 10 Minutes? If the user can't set it himself, provide that information in the label: "When Battery Critical (5%)"
- fixed, the number of minutes is configurable now, overriding HAL's poor defaults --sebas
- Lid Closed:
- Lid Closed should not be grouped with battery powered - it currently applies to both states. Alternatively, two lid closed might be introduced - having different settings for powered/battery is a use case for certain user groups. They may download huge files or compile in powered mode, but not in battery mode.
- What is "blank"? "Screen Saver", "Blank Screen" or "Monitor off"?
- There was no reaction on my Samsung P30 to this setting.
- Confirmation:
- The settings window is instant apply. We've not yet come to a final decision regarding instant apply for the HIG, but by consistency reasons I suggest not to use instant apply right now. In this case, there is also no direct feedback for battery critical or lid closed - as most KDE users are not used to instant apply, they might not know if the setting is applied immediately or if they have to click "close". In the worst case they expect the title close button to reset the changes. If you still decide to keep instant apply, add a button to revert changes. Changing to explicit apply would imply to make it a configuration dialog instead of the left-click action. Left click might then, for example, show a slider to set the current brightness (similar to KMix) (+ status info?).
- fixed: It's now a KDialog with OK and apply buttons. --sebas
- Brightness Preview:
- Currently there is only a brightness preview for the currently active scheme (_either_ mains or battery powered). That means if you want to set the battery brightness when you are currently mains powered, you'll probably move the battery slider, realise that there is no preview, go to the mains slider, move it till you found a nice brightness level, then go back to the battery slider and set it there. Would be nicer to have a preview for both sliders: Whenever you move to a new location, the brightness is adjusted. Has to be tested if it should be set back to previous value after 5 seconds, or if it should remain till you either move the other slider or click save (assuming explicit apply).
- 'somewhat fixed': You can set the brightness and will get immediate response. If cancel is pressed, settings are reverted, they're saved on [OK]. There is no 'preview' for the not-active state (on battery, on AC) --sebas
Allee:
- What I miss here is how 2 Batteries and 2 CPUs are handled. IMHO we need a place where status of all batteries and all CPU are shown.
- multiple CPUs is implemented, multiple batteries is not (I don't have a second battery I can plug in) --sebas
Chase:
- Can we get an option to turn off the on-screen display? Even like the k3b OSD that you can right-click and ask it to go away.
Feedback can be reported on KubuntuPowerManagementFeedback page.
