Re: [Utopia] Gnome Power Manager, updated screenshots

[David Zeuthen <david fubar dk>]

On Mon, 2005-04-25 at 20:26 +0100, Richard Hughes wrote:
> I've digested most of your comments and come up with the attached - not
> in CVS - just for me playing around.
> 
> Comments of mine:
> * The combo box at the top is only present with battery hardware.
>  (combo is needed to avoid having a huge duplication in UI)
> * Batteries (laptop, mice, etc) when low always give warnings.
> * Only one icon is displayed, optionally, except when devices (e.g.
> mice) are low, when multiple icons are shown.
> * Suspend options are now suffixed with (to disk) and (to RAM)
> * "Mains" (apparently a UK thing...) has been replaced with "power
> adapter"
> * There are LOTS less options - to keep things simple.
> * GNOME prefix removed.
> * Buttons that you don't have (e.g. suspend) don't show
> * Lid "button" clarified.
> * The "useful" (not) tooltips have disappeared.
> * The removal of the helper icons have made everything minimal - have I
> gone too far here?
> * Tooltips are now multiline and minimally display all devices.
> 
> Please, comments. When I'm happy with the UI I'll start working on the
> real "guts" of G-P-M, and it'll start doing interesting things.

This looks really really good, this has come a long way. One minor
nitpick is that perhaps it's not super interesting to adjust the timeout
for hard disk spin down, perhaps just provide a check box? 

Another, technical, thing is that g-p-m needs to know what sleep options
are available and adjust the user interface as appropriate since not all
vendors ship with suspend-to-disk, some architectures can't
suspend-to-ram, some systems don't have lid buttons etc. etc.

Perhaps the sleep options is something hal should somehow know (never
mind the details from where we get this for now) and tell g-p-m? I think
so, I'm thinking hal would export the following properties on the
computer object 

 bool power_management.sleep.can_quick_sleep (in ACPI this is S1)
 bool power_management.sleep.can_deep_sleep  (in ACPI this is S3)
 bool power_management.sleep.can_hibernate   (in ACPI this is S4)

 (btw, today we already have power_management.is_enabled, .type 
  and .acpi.linux.version)

to suitably abstract the various ways the system sleep. This is not to
say g-p-m should map that 1-1 to the user interface; what could be
interesting would be to have g-p-m manage running->S1->S3->S4 after a
suitable interval. For this to work we'd also want

 bool power_management.sleep.can_wakeup_during_sleep

and the pseudo-code in g-p-m would look like this

/** Call this function to put the system to sleep; will gradually
 *  put the system into deeper and deeper sleep states
 */
void
gpm_put_to_sleep (void)
{
  /* first do light sleep for one hour; system will come up
   * very quickly (2-3 seconds) */
  if (hal_put_into_quicksleep (1*60*60) != WAKEUP_FROM_ALARM)
    goto resumed_because_of_user;

  /* then deep sleep for 12 hours; system will come up after
   * 5-10 seconds */
  if (hal_put_into_deepsleep (12*60*60) != WAKEUP_FROM_ALARM)
    goto resumed_because_of_user;

  /* finally hibernate; it will take ~ 30 secs to resume system */
  assert (hal_put_into_hibernate (WAKEUP_NEVER) == WAKEUP_FROM_USER);
}

Given all this, I now argue we don't need to bother the user with
selecting sleep type (which is, as seen earlier in the thread, kind of
confusing) since we just do S1->S3->S4 and the user deals with it taking
longer to resume the system the longer it's been idle (this is how
Windows XP works I think). How about doing that?

Thanks,
David