[maemo-developers] [maemo-developers] Maemo Alarm/Notifier Interface

[From: Jason Mills]

On 2006-01-16, Dave Neuer wrote:
> 
> On 2006-01-16, Igor Stoppa wrote:
> > 
> > On Mon, 2006-01-16 at 17:21 +0200, ext David Weinehall wrote:
> > >
> > > A mechanism for wake-up from power-off exists (yes, it's a bit sucky,
> > > so we'll have to have a workaround for alarms >24h into the future,
> > > but at least it's possible) -- check
> > >
> > > Power management efficient enough to make suspend meaningless -- check
> > >
> > > I cannot really understand why a lot of people here seem to want
> > > crippled functionality just because other platforms have limitations.
> >
> > I understand that if we want to have a consistent crossdevice platform,
> > then it should be able to deal with other HW that doesn't have as many
> > power management features as OMAP, but that is not really a good reason
> > to discard what we _do_ have.
> >
> > Suspend is good compared to poweroff because it can retain the state of
> > the device and usually trim down startup/shutdown times, but it's
> > useless if the device actually manages to transparently and silently
> > save energy.
> 
> I agree. There is the issue of API -- that is where cross-platform
> comes in. Designing a good API for this IMO would take the ALSA
> approach; the API should have sane defaults and the library sane
> default configurations to make simpler hardware work w/ minimal
> effort, but don't dumb down the interface or implementation to the
> point where more advanced hardware can't be fully exploited.
> 
> Dave


The overall Maemo / Hildon interface specification is still young enough that
one could do it right, the first time.

Based on how that specific piece of hardware behaves, one can map an
arbitrary location in N-space (based on _end user_ interface responses) to a
specific set of actual hardware settings, without having to expose the actual
hardware at the _application_ or _end user_ layers.


For example:

A Control Panel widget which has the following sliders (some are binary
sliders, mind you)...

Optimize CPU for:
    Performance .....^...... Per-Charge Run-Time
    (Enables / disables DynTick, for example)

Deliver Alarms:
   As Scheduled ^........... At Subsequent Wake-Up
   (Enables / disables wake-on-alarm, for example)

Optimize System Suspend for:
      Fast Wake ..^......... Power Efficiency
      (Enables suspend-to-ram vs suspend-to-disk)

...etc...


Anyhow, the point is that if you ask questions which are logical from an end
user's perspective, they can be mapped to most any hardware back-end. Geeks
could always tweak the values of the sliders directly via GConf, causing the
UI to reflect new slider locations.

-JMills