/*! * \page enhance Enhancements * \section enhance_sec All planed or to be discussed enhancements/ enhancement requests. * * \subsection enhance_device_powermanagemnt Runtime device powermanagement * \b [Priority: \b M] (for v0.8) \n \n * Add device/runtime powermanagement to TDEPowersave and make it scheme specifi configurable via * the configure dialog. At least allow this for 'Advanced Powersave' scheme. \n \n * The powersave interface for this feature already exist, now we should allow the user to * change it. \n \n \n * * \subsection enhance_CPUhotplugging CPU Hotplugging * \b [Priority: \b M] (for v0.8) \n \n * Add CPU hotplugging to TDEPowersave. Allow enable/disable CPUs/Cores on multiprocessor/multicore * machines. We need scheme specific configuration. (translations and needed strings are already * added to TDEPowersave) \n \n \n * * \subsection enhance_configure_display Display battery and CPU informations in the configure dialog * \b [Priority: \b I] (for v0.8) \n \n * It would be really usefull to display all known information about the current state of the machine * and powersave/TDEPowersave in a new page in the configure dialog. This enclose CPU, Battery and * current scheme.\n \n \n * * \subsection enh_ControlCenter_plugin Plugin for the Trinity Control Center * \b [Priority: \b D] \n \n * It would be really usefull and easier/plainer for the user to add the configuredialog also to the * Trinity Control Center. By this we can remove the klaptop-plugin under SUSE from the Control Center by * default. So the user would be no longer confused through the klaptop plugin, which is obsolete under * SUSE. \n \n * We maybe also can move some/all of the powersave YaST-dialog to the dialog. We can use 'Administrator * Mode' to protect this settings. This would be usefull for other distributions. \n \n \n * * \subsection enh_tooltip Tooltip * \li \b CPU \b Tooltip \b like \b kicker \b mouseover \b effects \n \n * \b [Priority: \b I] \n \n * I like the nice mouseover effects on Kicker. Unforunately there is currently no QWidget for this. * If we would implement this we need to adapt the wifget from amarok/src/tracktooltip.cpp. * * \li \b Battery \b estimated \b empty \b at \b xx:yy \b in \b Tooltip \n \n * \b [Priority: \b I] \n \n * It would be nice to be to know when (estimated) the battery is empty and not only to know remaining hours. * * \li \b Optional \b full \b information \b Tooltip \n \n * \b [Priority: \b I] \n \n * We need a optional "amarok-like" Tooltip to display more of the already existing and collected information * like current scheme, battery state, battery fill state, cpu freq ... and a icon/picture representing the * current battery state. There should be a option in the configure dialog to switch beetween the normal and * the enhanced tooltip. * * \li \b CPU \b Temperature \b in \b Tooltip \n \n * \b [Priority: \b D] \n \n * It would be nice to be able to add the current CPU temperature to the tool tip. We maybe could get this * information from powersave or we need to poll a configured path in /proc/acpi/* . The user should be * able to configure if he would like use this new or the normal tooltip. The best would be to read * the settings by default from the kicker settings and add also an own tdepowersave option. * * \subsection enh_osd On Screen Display * \b [Priority: \b F] \n \n * It would be usefull to have configureable OSD to display permanent or event-based information for * the user on the display. Possible displayed events: * \li daemon.scheme.change * \li acadapter.offline, acadapter.online * \li battery.normal (full charged ), battery.warning, battery.low, battery.critical * \li battery.info (displayed as permanent only) * \li temperature.hot, temperature.critical * \li processor.performance, processor.powersave, processor.dynamic * \li cpu freq (displayed as permanent only ) \n \n * * * \n \n * \section design All to discuss and research design enhancements * * * \n \n \n \n * \subsection LEGEND LEGEND * \b Priority: * \li \b M (Mandatory): \n \n * The stable release shipment will be dependant on this component being included * within the release.\n \n * \li \b I (Important): \n \n * Adds significant features. Important features are stretch targets for this * release. Important features will become mandatory in the next release cycle.\n \n * \li \b D (Desirable): \n \n * Adds considerable value. Desirable features are targets of opportunity for * this release. Desirable features may or may not become mandatory features * over time.\n \n * \li \b F (Future): \n \n * This requirement has been deferred to a future release. It is listed for * informational purposes so that product development may make informed * architectural choices.\n \n * \li \b R (Rejected): \n \n * This requirement was suggested, but rejected as not in harmony with the value * proposition or positioning of the project. It will never be fulfilled.\n \n */