RFC: utilities to prevent standby
frm
today computers often use very aggressive energy settings which put
the PC in standby after few minutes of user inactivity (and this is
"ecologically" fine! ;)).
The trouble is that utilities which cannot be interrupted (e.g. those
which burn CDs, those which are doing long calculations, etc etc)
should signal their status to the OS so that even if the user is
inactive, the PC won't go in standby during the critical operations.
I've recently added to one of my (wx-based) program a call to the
SetThreadExecutionState() API which informs Windows about critical
operations. Does anyone knows API calls like those for other operating
systems (mac and linux)?
If there are the equivalents of SetThreadExecutionState() on other
OSes I'd suggest adding a couple of global utilities to wx; e.g.:
Index: include/wx/utils.h
===================================================================
--- include/wx/utils.h (revision 63842)
+++ include/wx/utils.h (working copy)
@@ -126,9 +126,16 @@
// Return path where wxWidgets is installed (mostly useful in Unices)
WXDLLIMPEXP_BASE const wxChar *wxGetInstallPrefix();
+
// Return path to wxWin data (/usr/share/wx/%{version}) (Unices)
WXDLLIMPEXP_BASE wxString wxGetDataDir();
+// Tells the OS that it should not enter standby until
wxLeaveStandbyPreventSection() is called.
+WXDLLIMPEXP_BASE wxEnterStandbyPreventSection();
+
+// Tells the OS that standby is now allowed again.
+WXDLLIMPEXP_BASE wxLeaveStandbyPreventSection();
+
#if wxUSE_GUI
// Get the state of a key (true if pressed, false if not)
Index: src/msw/utils.cpp
===================================================================
--- src/msw/utils.cpp (revision 63842)
+++ src/msw/utils.cpp (working copy)
@@ -1075,6 +1075,18 @@
#endif
}
+void wxEnterStandbyPreventSection()
+{
+ // prevent the sleep idle time-out:
+ SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED);
+}
+
+void wxLeaveStandbyPreventSection()
+{
+ // clear the ES_SYSTEM_REQUIRED flag set by
wxEnterStandbyPreventSection()
+ SetThreadExecutionState(ES_CONTINUOUS);
+}
+
//
----------------------------------------------------------------------------
// OS version
//
----------------------------------------------------------------------------
Do you think this addition (functions for preventing standby) would be
fine in wx? And if you think it is, do you think that global functions
like those I proposed above (with maybe also a little C++ wxLogNull-
like class, wxStandbyPrevent, which calls the functions in the ctor
and dtor) would be ok?
Thanks,
Francesco
Vadim Zeitlin
f> I've recently added to one of my (wx-based) program a call to the
f> SetThreadExecutionState() API which informs Windows about critical
f> operations. Does anyone knows API calls like those for other operating
f> systems (mac and linux)?
For Linux this would use DBUS or maybe DeviceKit and so the problem is,
again, lack of any way to use DBUS easily from wx. I'd really like to add
it as it's also needed for power events generation (I'm peeved that
Mahogany currently can reopen all folders when resuming from suspend under
Windows but not Linux) and probably many other aspects of desktop
integration.
f> If there are the equivalents of SetThreadExecutionState() on other
f> OSes I'd suggest adding a couple of global utilities to wx; e.g.:
I think it would be better to add them as wxApp members because we may
need to do something else than simply calling a function in other
implementations. To be honest I thought that even under Windows you could
only use SetThreadExecutionState() under Vista and later and that you had
to handle WM_POWERBROADCAST with PBT_APMQUERYSUSPEND (which would need to
be done in wxApp) but apparently I was wrong as the function is present in
all Windows versions since Windows 2000. OTOH maybe it doesn't work in
versions prior to Vista, did you test it under XP by chance?
Also, in any case, we need to load it dynamically to not prevent the
applications using it from even starting up on Win9x systems.
f> Do you think this addition (functions for preventing standby) would be
f> fine in wx?
Yes, I definitely think we want to have them, just not in (exactly) this
form.
f> And if you think it is, do you think that global functions
f> like those I proposed above (with maybe also a little C++ wxLogNull-
f> like class, wxStandbyPrevent, which calls the functions in the ctor
f> and dtor) would be ok?
I'd like to have wxStandbyPrevent in any case but the functions should
probably be in wxApp or maybe in some new class in wx/power.h. I'd also
like to know what happens if you call Enter() twice and Leave() once:
currently this will allow the machine to enter standby but I think it's
wrong behaviour and there should be a reference count here, as usual. If
not, it would at least need to be documented.
It would also be nice to look at what exactly needs to be done with DBUS,
maybe this would influence the API design as well. And unfortunately I
couldn't find how to do it this under OS X. I only found
NSWorkspaceWillSleepNotification notification but it doesn't seem to allow
us to veto sleeping as the documentation says that we can only disable
sleep by 30 seconds. OTOH this class (NSWorkspace) should probably be
used for power events generation. Ah, wait, there is also NSWorkspace::
extendPowerOffBy: method -- does anybody know if this is what should be
used to prevent the system from sleeping?
Thanks,
VZ
Francesco
2010/4/4 Vadim Zeitlin <va...@wxwidgets.org>:
> On Sun, 4 Apr 2010 03:00:57 -0700 (PDT) frm <francesco...@gmail.com> wrote:
>
> f> I've recently added to one of my (wx-based) program a call to the
> f> SetThreadExecutionState() API which informs Windows about critical
> f> operations. Does anyone knows API calls like those for other operating
> f> systems (mac and linux)?
>
> For Linux this would use DBUS or maybe DeviceKit and so the problem is,
> again, lack of any way to use DBUS easily from wx.
In the past I only found some few infos about HAL+DBUS (see
http://projects.gnome.org/gnome-power-manager/); DeviceKit-power has
no documentation it seems...
Luckily I've just got a reply on gtk-app-devel which pointed me to:
http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit
now the question is only how to use it... :)
> f> If there are the equivalents of SetThreadExecutionState() on other
> f> OSes I'd suggest adding a couple of global utilities to wx; e.g.:
>
> I think it would be better to add them as wxApp members because we may
> need to do something else than simply calling a function in other
> implementations.
well, also from a logical POV wxApp seems to be a better place for
this... (wxGetApp().EnterStandbyPreventSection() seems slightly better
to read as it emphasizes that this a request to the OS from the
current application).
>To be honest I thought that even under Windows you could
> only use SetThreadExecutionState() under Vista and later and that you had
> to handle WM_POWERBROADCAST with PBT_APMQUERYSUSPEND (which would need to
> be done in wxApp) but apparently I was wrong as the function is present in
> all Windows versions since Windows 2000. OTOH maybe it doesn't work in
> versions prior to Vista, did you test it under XP by chance?
not yet, will do.
> Also, in any case, we need to load it dynamically to not prevent the
> applications using it from even starting up on Win9x systems.
ok, btw maybe we could decide to drop support for Win9x platforms at
some point in the future. E.g. I think it would be really fine to have
wx3.2 branch run only on Win >= NT...
> f> Do you think this addition (functions for preventing standby) would be
> f> fine in wx?
>
> Yes, I definitely think we want to have them, just not in (exactly) this
> form.
ok, great.
> f> And if you think it is, do you think that global functions
> f> like those I proposed above (with maybe also a little C++ wxLogNull-
> f> like class, wxStandbyPrevent, which calls the functions in the ctor
> f> and dtor) would be ok?
>
> I'd like to have wxStandbyPrevent in any case but the functions should
> probably be in wxApp or maybe in some new class in wx/power.h. I'd also
> like to know what happens if you call Enter() twice and Leave() once:
> currently this will allow the machine to enter standby but I think it's
> wrong behaviour and there should be a reference count here, as usual. If
> not, it would at least need to be documented.
I think a reference count would be the best thing: more uniform with
the rest of the wx api and more sensed.
> It would also be nice to look at what exactly needs to be done with DBUS,
> maybe this would influence the API design as well. And unfortunately I
> couldn't find how to do it this under OS X. I only found
> NSWorkspaceWillSleepNotification notification but it doesn't seem to allow
> us to veto sleeping as the documentation says that we can only disable
> sleep by 30 seconds. OTOH this class (NSWorkspace) should probably be
> used for power events generation. Ah, wait, there is also NSWorkspace::
> extendPowerOffBy: method -- does anybody know if this is what should be
> used to prevent the system from sleeping?
any Mac expert around? :)
Francesco
Vadim Zeitlin
F> In the past I only found some few infos about HAL+DBUS (see
F> http://projects.gnome.org/gnome-power-manager/); DeviceKit-power has
F> no documentation it seems...
I think I found examples of doing what we want though...
F> Luckily I've just got a reply on gtk-app-devel which pointed me to:
F> http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit
F> now the question is only how to use it... :)
Last time I looked I couldn't find any high level C++ library that we
could use (either for licencing reasons or because of extra dependencies).
So unfortunately I don't think there is any alternative to using just the
low level D-Bus C API and doing everything ourselves. Luckily, we don't
need that much. Unluckily this is still probably a lot of work...
FWIW there is an even more masochistic possibility of not even using
libdbus but working directly with the protocol. But I don't think it's
worth doing this.
F> ok, btw maybe we could decide to drop support for Win9x platforms at
F> some point in the future. E.g. I think it would be really fine to have
F> wx3.2 branch run only on Win >= NT...
Yes, I think this should be fine. And drop MSVC6 too by then...
Regards,
VZ
iko...@earthlink.net
Well, the current trunk is not supported by MSVC 5, but the code is still checking
for it....
I think we need to start with this one. ;-)
Thank you.
>
> Regards,
>VZ