Wishlist/ANARM

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Morse code or synthesized speech ringtone)
(changed "notification modes" to more commonly used term "profiles")
Line 1: Line 1:
 
{{Wishlist}}
 
{{Wishlist}}
The Advanced Notification And Ringtone Manager is an application for handling all event-based audible notifications from an OpenMoko device.  Would determine whether or not it is an appropriate time to audibly notify a user of various events, by checking the current [[#Notification Modes|notification mode]].
+
The Advanced Notification And Ringtone Manager is an application for handling all event-based audible notifications from an OpenMoko device.  Would determine whether or not it is an appropriate time to audibly notify a user of various events, by checking the current [[#Profiles|profiles]].
 
The overall operation is analagous to a firewall.  It would also provide the interface for any application to create notifications through inter-process communication(using dbus?). It might be closely connected to the [[Wishlist:Point_of_Interest_Framework]]
 
The overall operation is analagous to a firewall.  It would also provide the interface for any application to create notifications through inter-process communication(using dbus?). It might be closely connected to the [[Wishlist:Point_of_Interest_Framework]]
  
=== Notification Modes ===
+
=== Profiles ===
Notifications are allowed or denied(silenced) based on the current Notification Mode, which is set by the user on the fly.
+
Notifications are allowed or denied(silenced) based on the current Profile, which is set by the user on the fly.
A mode consists of an set of "firewall rules".  Each rule can either ALLOW or DENY notifications for a single [[#Events|event]], or [[#Event Classes|class of events]].
+
A profile consists of an set of "firewall rules".  Each rule can either ALLOW or DENY notifications for a single [[#Events|event]], or [[#Event Classes|class of events]].
Each notification mode and its rules are independent from other modes.
+
Each profile and its rules are independent from other profiles.
The current notification mode could be selected manually, or automatically depending on time of day or possibly even the GPS location.
+
The current profile could be selected manually, or automatically depending on time of day or possibly even the GPS location.
Notification modes are like DEFCON levels for an OpenMoko device.
+
profile are like DEFCON levels for an OpenMoko device.
  
Examples of possible modes:
+
Examples of possible profiles:
 
*Completely free
 
*Completely free
 
*Hard at work
 
*Hard at work
Line 32: Line 32:
  
 
=== Event classes ===
 
=== Event classes ===
Event classes can optionally be defined for the purpose of simplify Notification Mode rulesets.  Instead of making a separate rule for every event, rules can be defined for an entire class of events.
+
Event classes can optionally be defined for the purpose of simplifying profile rulesets.  Instead of making a separate rule for every event, rules can be defined for an entire class of events.
 
An event can belong to a number of classes, similar to a *nix user belonging to permission groups.
 
An event can belong to a number of classes, similar to a *nix user belonging to permission groups.
 
Examples of possible event classes:
 
Examples of possible event classes:

Revision as of 03:31, 22 July 2008

Wishes warning! This article or section documents one or more OpenMoko Wish List items, the features described here may or may not be implemented in the future.

The Advanced Notification And Ringtone Manager is an application for handling all event-based audible notifications from an OpenMoko device. Would determine whether or not it is an appropriate time to audibly notify a user of various events, by checking the current profiles. The overall operation is analagous to a firewall. It would also provide the interface for any application to create notifications through inter-process communication(using dbus?). It might be closely connected to the Wishlist:Point_of_Interest_Framework

Contents

Profiles

Notifications are allowed or denied(silenced) based on the current Profile, which is set by the user on the fly. A profile consists of an set of "firewall rules". Each rule can either ALLOW or DENY notifications for a single event, or class of events. Each profile and its rules are independent from other profiles. The current profile could be selected manually, or automatically depending on time of day or possibly even the GPS location. profile are like DEFCON levels for an OpenMoko device.

Examples of possible profiles:

  • Completely free
  • Hard at work
  • Asleep
  • On-call
  • Device currently in use
  • Do not disturb
  • etc.

Events

An event is anything that could possibly trigger a notification. Each event can be assigned it's own unique sound file. In addition to standard phone events(incoming calls, text messaging), events can come from any number of applications that communicate with Notification Manager. Examples of possible events:

  • Incoming call (could define specific events per caller)
  • SMS
  • New email
  • Instant Messaging
  • Calendar alarm
  • Updated RSS feed
  • Stock price change

Event classes

Event classes can optionally be defined for the purpose of simplifying profile rulesets. Instead of making a separate rule for every event, rules can be defined for an entire class of events. An event can belong to a number of classes, similar to a *nix user belonging to permission groups. Examples of possible event classes:

  • Calls from family
  • Calls from friends
  • Unknown caller
  • New email
  • Vital to survival
  • etc

Morse code or synthesized speech ringtone

For ringtones, SMS, emails, and calendar alerts, a special ringtone mode could generate beeps according to the Morse code or use speech synthesis. For a know phone number or known email the caller or sender name (and indication mobile, private or work) could be used in as a ringtone. Implementing this will be handy if you cannot see your phone because of the work you are doing and you only want to answer the call or read the message if a certain person is calling because e.g. a lot of effort is involved in making a small pause in your work. As a marine geek feature even a steam whistle could be used in stead of the standard Morse bleeps.

Also individual ringtones per caller/sender and mobile/private/work could be stored in the address book which override any ring tone scheme which has been selected.

Personal tools
Wishes warning! This article or section documents one or more OpenMoko Wish List items, the features described here may or may not be implemented in the future.

The Advanced Notification And Ringtone Manager is an application for handling all event-based audible notifications from an OpenMoko device. Would determine whether or not it is an appropriate time to audibly notify a user of various events, by checking the current notification mode. The overall operation is analagous to a firewall. It would also provide the interface for any application to create notifications through inter-process communication(using dbus?). It might be closely connected to the Wishlist:Point_of_Interest_Framework

Notification Modes

Notifications are allowed or denied(silenced) based on the current Notification Mode, which is set by the user on the fly. A mode consists of an set of "firewall rules". Each rule can either ALLOW or DENY notifications for a single event, or class of events. Each notification mode and its rules are independent from other modes. The current notification mode could be selected manually, or automatically depending on time of day or possibly even the GPS location. Notification modes are like DEFCON levels for an OpenMoko device.

Examples of possible modes:

  • Completely free
  • Hard at work
  • Asleep
  • On-call
  • Device currently in use
  • Do not disturb
  • etc.

Events

An event is anything that could possibly trigger a notification. Each event can be assigned it's own unique sound file. In addition to standard phone events(incoming calls, text messaging), events can come from any number of applications that communicate with Notification Manager. Examples of possible events:

  • Incoming call (could define specific events per caller)
  • SMS
  • New email
  • Instant Messaging
  • Calendar alarm
  • Updated RSS feed
  • Stock price change

Event classes

Event classes can optionally be defined for the purpose of simplify Notification Mode rulesets. Instead of making a separate rule for every event, rules can be defined for an entire class of events. An event can belong to a number of classes, similar to a *nix user belonging to permission groups. Examples of possible event classes:

  • Calls from family
  • Calls from friends
  • Unknown caller
  • New email
  • Vital to survival
  • etc

Morse code or synthesized speech ringtone

For ringtones, SMS, emails, and calendar alerts, a special ringtone mode could generate beeps according to the Morse code or use speech synthesis. For a know phone number or known email the caller or sender name (and indication mobile, private or work) could be used in as a ringtone. Implementing this will be handy if you cannot see your phone because of the work you are doing and you only want to answer the call or read the message if a certain person is calling because e.g. a lot of effort is involved in making a small pause in your work. As a marine geek feature even a steam whistle could be used in stead of the standard Morse bleeps.

Also individual ringtones per caller/sender and mobile/private/work could be stored in the address book which override any ring tone scheme which has been selected.