< Desktop | Whiteboards
No edit summary |
No edit summary |
||
Line 30: | Line 30: | ||
* Not sure about this one | * Not sure about this one | ||
* | * Inhibiting idleness would not be good because we want to power down the screen | ||
* Probably inhibiting suspend is the right choice | |||
'''Burning a CD''' | '''Burning a CD''' | ||
Line 84: | Line 85: | ||
|- | |- | ||
|} | |} | ||
It should be stressed that Inhibiting is not the same as blocking. The same was chosen to express a difference. An Inhibit should: | |||
* prevent automatic/non-interactive actions | |||
Example: prevent automatic suspend after a period of idleness | |||
* inform manual/interactive actions | |||
Example: Inform the user about the risk of dataloss when selecting power off from the menu | |||
* not interfere with manual/non-interactive actions | |||
Example: Closing the lid when there is no way to interact with the user should not block suspend | |||
References | References | ||
* http://bugzilla.gnome.org/show_bug.cgi?id=334809#c6 | * http://bugzilla.gnome.org/show_bug.cgi?id=334809#c6 |
Revision as of 21:52, 31 October 2008
Problem
The Inhibit pattern has proven to be quite successful. It is a good way for applications to proactively inform the system about actions that should not be taken.
Firstly, we offer too many ways to do this. We currently (as of GNOME 2.24) have the following:
* http://www.gnome.org/~mccann/gnome-screensaver/docs/gnome-screensaver.html#gs-method-Inhibit * http://people.freedesktop.org/~hughsient/temp/dbus-interface.html#dbus-inhibit * http://www.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit
Secondly, it is not always possible to know ahead of time if an action should be avoided. So, there is often a need for the [pattern]. This pattern has been partially implemented in gnome-session 2.24. See http://live.gnome.org/SessionManagement/GnomeSession .
Use Cases
Watching a movie on laptop screen
* Movie player should inhibit idleness
Close laptop lid: * Suspend
Watching a movie with laptop plugged into an external monitor/TV
* Movie player should inhibit idleness Close laptop lid: * Turn off laptop panel backlight * Do not suspend until after next idle period after movie finishes playing
Listening to music on laptop in another room
* Not sure about this one * Inhibiting idleness would not be good because we want to power down the screen * Probably inhibiting suspend is the right choice
Burning a CD
* Perfectly fine to be idle and lock the screen if necessary * Inhibit suspend * Inhibit user switch (once we have frevoke) * Inhibit logout * Not necessary to inhibit reboot or shutdown since logout and switch are inhibited
Transferring files to a removable disk
* Same as Burning a CD
Performing a core system software update
* Only inhibit system reboot/shutdown?
Performing an application software update
* Only inhibit system reboot/shutdown? * Maybe even fail and try again
Editing a document
* Only inhibit logout
Playing a game
* Inhibit idleness
Discussion
Overview of actions
Action | Interface |
---|---|
Session idleness | org.gnome.ScreenSaver.Inhibit |
Automatic screen locking | org.gnome.ScreenSaver.Inhibit |
Switching users | org.gnome.SessionManager.Inhibit |
Automatic suspend | org.freedesktop.PowerManagement.Inhibit |
Automatic hibernation | org.freedesktop.PowerManagement.Inhibit |
Logout | org.gnome.SessionManager.Inhibit |
Reboot/Shutdown | TBD |
It should be stressed that Inhibiting is not the same as blocking. The same was chosen to express a difference. An Inhibit should:
* prevent automatic/non-interactive actions Example: prevent automatic suspend after a period of idleness * inform manual/interactive actions Example: Inform the user about the risk of dataloss when selecting power off from the menu * not interfere with manual/non-interactive actions Example: Closing the lid when there is no way to interact with the user should not block suspend
References
* http://bugzilla.gnome.org/show_bug.cgi?id=334809#c6