KubuntuPowerManagement
|
Size: 6170
Comment: beta comments
|
← Revision 25 as of 2008-08-06 16:21:08 ⇥
Size: 9422
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 11: | Line 11: |
(Make this: '''an universal power management daemon with a KDE GUI'''. Read comments Elias12 for explanation.)''' |
|
| Line 40: | Line 42: |
| http://kubuntu.org/~jriddell/power-config.png | {{http://kubuntu.org/~jriddell/power-config.png}} |
| Line 44: | Line 46: |
| http://kubuntu.org/~jriddell/power-tooltip.png | {{http://kubuntu.org/~jriddell/power-tooltip.png}} |
| Line 48: | Line 50: |
| http://kubuntu.org/~jriddell/power-menu.png | {{http://kubuntu.org/~jriddell/power-menu.png}} |
| Line 57: | Line 59: |
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. |
|
| Line 58: | Line 67: |
| * I am missing configuration for action to perfom on Close Lid and Sleep/Suspend key. | * 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 |
| Line 61: | Line 71: |
| * brightness controls are not shown when HAL doesn't show a brightness device --sebas | |
| Line 67: | Line 78: |
| * The KPowersave redesign would've taken too long (there's not code yet, after UVF) | |
| Line 73: | Line 85: |
| * fixed --sebas | |
| Line 74: | Line 87: |
| * fixed --sebas | |
| Line 75: | Line 89: |
| * fixed, please confirm --sebas | |
| Line 76: | Line 91: |
| * fixed, the number of minutes is configurable now, overriding HAL's poor defaults --sebas |
|
| Line 77: | Line 94: |
| * Lid Closed should not be grouped with battery powered - it applies to both states. | * 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. * fixed --sebas |
| Line 82: | Line 100: |
| * fixed: It's now a KDialog with OK and apply buttons. --sebas |
|
| Line 84: | Line 104: |
| * '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. |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/kubuntu-power-management
Created: 6/6/06 by JonathanRiddell
Contributors: JonathanRiddell, LukaRenko
Packages affected: klaptopdaemon, powersave, kpowersave
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.)
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.
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.
KDE frontend to the properties exposed by HAL. Any laptop specific issues should be solved below HAL.
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 http://vizzzion.org/?id=viewpic&gcat=UbuntuDevSummitParis&gpic=IMG_7851.JPG#images http://vizzzion.org/?id=viewpic&gcat=UbuntuDevSummitParis&gpic=IMG_7852.JPG#images Code can be found at: http://websvn.kde.org/trunk/playground/base/guidance/powermanager/
Elias12: Ellen: Didn't we agree on having three "Active Schemes" -> Powersave, Automatic and Performance that are added as an option to the plugged/unplugged profile? 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! ). Ellen (2006-08-10): Beta Review Unclear what the ticks represent -> percentage? levels? Provide an indicator at least in the tooltip. Allee: Chase: Feedback can be reported on KubuntuPowerManagementFeedback page. Rationale
Use cases
Scope
Design
Comments
KubuntuPowerManagement (last edited 2008-08-06 16:21:08 by localhost)