Version: ukendt (using 4.3.4 (KDE 4.3.4), Chakra KDE) Compiler: gcc OS: Linux (x86_64) release 2.6.31-ARCH I think KDE needs a dbus signal that notifies interrested parties about system resume after suspend or hibernate. Obvious users are plasmoids that updates in time intervals, such as clocks, scripted images etc. I know that kalarm is also a likely user.
It is now implemented in 4.6 - will blog soon about it.
You are my hero of the week! Now, plasmoid and application developers, go use it!
Adding blog link as requested by David: http://drfav.wordpress.com/2010/11/10/updates-from-kde-power-management-land-for-users-and-developers/
This will be really useful. But your blog says that it's only available with the upower backend. In that case, applications need to be able to find out whether the signal is actually available on the system - is that currently possible? KAlarm for one won't actually be able to use the signal unless it can know that it is definitely available.
(First of all: it will work on upower only because HAL does not support that) Btw, I will soon add a method backend() on the DBus interface, so that you can check whether the backend will be "upower" or "HAL". Will CCBUG this bug when I'll do that. P.S.: It is very unlikely that, on Linux, somebody will use HAL only with KDE 4.6.
Wouldn't it be better to provide a generalised function to query which features are available from the current backend? The benefits of this would be 1) Applications wouldn't need to know which backends provide which features. 2) Applications wouldn't have to be changed every time a new backend is implemented. 3) If a backend changes its feature set, there won't be the problem of applications having to know not only which backends provide which features, but also which versions of each backend provides which features.
Is there any progress on providing a way to discover programmatically whether the resume from suspend signal is available? I'd really like KAlarm to use the signal when available, but that still isn't an option without a discovery method. If the signal doesn't appear after a resume, KAlarm is likely to miss triggering alarms, and that's too important to take a chance on even if it will work on most systems. Because the signal will only be usable for KAlarm when it can be 100% relied on, I'm reopening the issue.
org.kde.Solid.PowerManagement.backendCapabilities was added by kde-workspace commit 715885499f15af5644ae7eff1232ceb219bf7d22 for 4.6 Is this good enough? I'm not sure why this wasn't mentioned here - maybe it was an oversight or maybe this isn't enough by itself. It certainly looks like it should meet your needs though.
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Please try again with the latest version and submit a new bug to frameworks-solid if your issue persists. Thank you!