This is the design specification for Notify OSD. If you are a software developer looking for advice on making your software compatible with Notify OSD, see NotificationDevelopmentGuidelines.

This specification contains some issues not yet resolved. Your feedback is welcome at NotifyOSD/Comments.

To improve the user experience for notifications in Ubuntu and Kubuntu, the Desktop Notifications Specification and the KNotification API should be implemented in a consistent way, with non-interactive, non-directional, non-overlapping notification bubbles that can be clicked through and look beautiful. For compatibility with this system, Ubuntu and Kubuntu software should be patched so that it does not rely on notifications being interactive or pointing to notification area icons, and when an unpatched program incorrectly requests a notification with actions it should be shown as an alert box. Any notification configuration should be handled by individual applications. Visual confirmation of hotkey changes to volume, screen brightness, and backlight brightness should also be presented in bubbles the same way as notifications.

Canonical Ltd’s Design team and Desktop Experience team are the upstream developers for this work. Notify OSD is hosted on Launchpad.

Contents

  1. Work for Lucid
  2. Rationale
  3. Use cases
  4. Targeted environments
  5. System nomenclature
  6. Bubble appearance and layout
    1. Inside the bubble
      1. Icon
      2. Text layout
      3. Title text
      4. Body text
      5. Gauge
      6. Interaction
    2. Outside the bubble
  7. Bubble behavior
    1. Animations and durations
    2. Sound
    3. Merging notifications
    4. Overflow of long messages
    5. Flood prevention
    6. “Do not disturb” mode
  8. Fallback alert boxes
  9. Logging notifications
  10. Critical and non-critical queues and do-not-disturb mode
  11. Treatment of the Desktop Notifications Specification 1.1
    1. org.freedesktop.Notifications.GetCapabilities
    2. org.freedesktop.Notifications.Notify
      1. Sanitizing body text
    3. org.freedesktop.Notifications.CloseNotification
    4. org.freedesktop.Notifications.GetServerInformation
    5. org.freedesktop.Notifications.NotificationClosed
    6. org.freedesktop.Notifications.ActionInvoked
  12. Treatment of the KNotification API
  13. Treatment of hotkeys
    1. Volume changes
    2. Brightness and backlight changes
    3. Disc ejection
    4. Play, Pause, Stop, Previous, and Next
  14. Treatment of hardware device detection
  15. Architecture
  16. Compatibility fixes accepted upstream
  17. Compatibility fixes still to be maintained
    1. amsn
    2. apport
    3. banshee
    4. bluez-gnome
    5. bzr-gtk
    6. debian-bts-applet
    7. decibel-audio-player
    8. emesene
    9. empathy
    10. evolution
    11. firefox
    12. gajim
    13. Giver
    14. gmail-notify
    15. gnome-disk-utility
    16. gnome-power-manager
    17. gnome-screensaver
    18. gnome-settings-daemon
    19. gnome-user-share
    20. gnoemoe
    21. goobox
    22. gossip
    23. gshutdown
    24. kerneloops
    25. kopete
    26. kpackagekit
    27. kwalletmanager
    28. liferea
    29. network-manager
    30. ontv
    31. openoffice.org-impress
    32. packagekit-gnome
    33. pidgin
    34. powerdevil
    35. quassel
    36. software-sources
    37. specto
    38. system-config-printer
    39. system-install-packages
    40. thunderbird
    41. timer-applet
    42. totem
    43. tracker
    44. vlc
    45. zeroinstall
    46. Orage
    47. Mail Notification
    48. cGmail
    49. MeMaker
    50. pastebin plasma widget
    51. Lancelot
    52. Phonon
  18. Release notes
  19. Unresolved issues

Work for Lucid

Rationale

There are many reasons that a computer may want to notify you of things not directly related to what you are doing right now. Software updates may be available; you may have received a new instant message; your 300-page print job may have finally finished; you may have only ten minutes of battery left. Sometimes these events need a response or at least acknowledgement, or don’t need to be read immediately, in which case they should be presented in an alert box or some other window. For cases where a notification is best read immediately but there is no applicable response, however, the most appropriate mechanism is a non-interactive notification bubble. (For more details on the various notification mechanisms and when to use each one, see NotificationDesignGuidelines.)

Ubuntu previously used notification-daemon, which presented notification bubbles as interactive and therefore risked accidental clicks. The previous bubbles were also rather unattractive, so replacing the notification system gave us the opportunity to make them beautiful. And presenting volume, brightness, and similar changes in the same way as notifications decreases visual variety, and introduces a consistent appearance for non-interactive things.

Use cases

Examples of notification bubbles and other forms of notification:

Examples of confirmation bubbles:

Targeted environments

It is most important for Notify OSD to work correctly with Compiz in either Ubuntu or Kubuntu, Metacity composited in Ubuntu, and kwin composited in Kubuntu.

Other targets are Metacity non-composited, kwin non-composited, xfwm4 non-composited, and xfwm4 composited.

System nomenclature

Notify OSD should be packaged under the name notify-osd. When running, its process should also be called notify-osd.

Bubble appearance and layout

Notify OSD should display two types of bubbles, which this specification calls confirmation bubbles (confirmation of e.g. change in sound volume, change in display brightness, or ejecting a CD) and notification bubbles (e.g. instant message, unrequested change in Internet connectivity).

For the purpose of this specification, the term leading means “left” whenever the system is using a left-to-right language, and “right” whenever the system is using a right-to-left language. The term trailing means “right” whenever the system is using a left-to-right language, and “left” whenever the system is using a right-to-left language. All mockups in this specification are of LTR layouts.

Inside the bubble

notification-bubble.jpg

Regardless of type, a bubble should appear as a rectangle of color #131313 (regardless of theme) with opacity 80%, corner roundness 0.375 em, and a drop shadow of #000000 color and 0.5 em spread. The bubble should blur whatever is behind it with a Gaussian blur of 0.125 em.

A bubble should be 24 ems wide (not including the drop shadow). Its height depends on the contents, but should be a minimum of 5 ems, and a maximum just tall enough to display 10 lines of body text (which means the maximum height of a bubble with a title is greater than of a bubble without a title). Furthermore, the bottom limit is 6 ems from the top of the bottom panel, if there is one, or otherwise 6 ems from the bottom of the screen (as if there was a 5-em bubble at the bottom plus 0.5 em margin on each side). Regardless of font and screen size, a bubble must not be so tall that it extends beyond the bottom limit.

Bubbles feature an icon, and/or some text or a gauge. All text elements should have a drop shadow of #000000 color and 0.125 em spread.

notification-bubble-layout-internal-1.png

Icon

Any icon should be scaled so that its largest dimension is 3 ems, while retaining the icon’s original aspect ratio. This means that vector and bitmap icons should be simple, without fine detail or thin strokes, and all icons should be square or nearly square whenever possible. If the icon is a bitmap, Sinc/Lanczos scaling should be used to minimize jagginess.

eject.jpg

If the bubble has no text, the icon should be horizontally centered within the window. Otherwise, the icon should be horizontally and vertically centered within a 3-em square that is flush with the leading side, with 1 em margin to the trailing side.

Icons representing alerts, warnings or errors should use an x or ? symbol with smooth gradient ranging from light red (#ff6363) at the top to dark red (#cc0000) at the bottom. Other than that, all icons and gauges should use one color theme: a smooth gradient ranging from light gray (#ececec) at the top to medium gray (#9b9b9b) at the bottom. Every icon should also use a black 2px outline with 30% opacity. There should also be a 1px white highlight with 40% opacity on the top and left edges to improve the definition. Different opacity values of this scheme (excluding the black outline) are allowed, for example to depict an inactive/disabled state or different levels of intensity (e.g. brightness). All icons and gauges should use gently rounded corners with the recommended roundness of 0.1 em radius and the roundness should not exceed 0.25 em radius.

notify-osd-default-icon-set.png

This set is subject to change.

Text layout

If there is text, it consists of a title and/or a body. Both of these should use the standard application typeface, aligned to the leading side, and should wrap to multiple lines if necessary. If a word is wider than the line, it should wrap following usual Pango rules for the current interface language.

Both title and body text should appear to the trailing side of the icon. If there is no body text, the title text should be vertically centered with the center of the icon. If there is body text, the title text should be top-aligned with the top of the icon, and the body text should begin immediately underneath. This applies even if body text is added to a bubble that previously had only a title: the title text should move from its centered alignment to top alignment as the body text appears.

Title text

The title should be the standard application font size, of color #ffffff, and bold weight.

In the title text, any string of one or more consecutive whitespace characters (U+0020 SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000C FORM FEED (FF), or U+000D CARRIAGE RETURN (CR)), even if a mixture of those, should be treated as a single space. Leading and trailing whitespace should not be presented.

If the title would take up longer than three lines, it should be truncated at just enough characters to fit an ellipsis character “…” at the end of the third line.

Body text

The body should be 0.9 × the standard application font size, of color #eaeaea, standard weight, and should not contain any extra formatting.

In the body text, any string of one or more consecutive whitespace characters that contains at least one newline (U+000D CARRIAGE RETURN (CR), U+000A LINE FEED (LF), or U+000D CARRIAGE RETURN (CR) immediately followed by U+000A LINE FEED (LF)), even if a mixture of those, should be treated as a single newline. Then for each line in the text, any string of one or more consecutive (non-newline) whitespace characters, even if a mixture of them, should be treated as a single space, and leading and trailing whitespace should not be presented.

Gauge

If a notification bubble has a gauge, the gauge should display the old value for 500 ms before switching to the new value for the remainder of the time, as a visual indication of what the change was.

Interaction

notification-mouseout.png notification-mouseover.png

Whenever a pointer moves into a bubble, whatever is behind the bubble should instantly become no longer blurred, and the bubble itself should instead receive a 2-pixel Gaussian blur and reduce to 40% opacity. (The bubble should not blur from the pointer being in the bubble area when it first appears, because you are unlikely to be aware of where the pointer is — it may not even be visible. And once you become aware, it is simple to move out then in again.) When the pointer leaves the bubble, the bubble should instantly return to its normal appearance.

Other than that hover effect, bubbles should not directly respond to input devices in any way.

Outside the bubble

If any windows are open, a bubble should appear on whichever display contains the largest fraction of the area of the focused window at the moment the bubble starts appearing. If no windows are open, a bubble should appear on whichever display the pointer is on at the moment the bubble starts appearing. (Except with MPX, a display has only one pointer. A touch-only display has an invisible pointer, so whenever it is touched it becomes the display that the pointer is on.)

Each display should show up to one confirmation bubble, plus up to one notification bubble, at a time. There should be a gconf key determining which of three positioning schemes are used. In all three schemes, the right edge of any bubble should be 0.5 em from the trailing edge of the display.

  1. A notification bubble should be positioned near the bottom right corner, such that if the bubble grows to its maximum height, it is 0.5em from the bottom of the display (or from the top of any panels at the bottom of the display). A confirmation bubble should use a slot immediately above that notification bubble slot.
  2. The bottom of a confirmation bubble should be 0.25 em above the vertical center of the display. The top of a notification bubble should be 0.25 em below the vertical center of the display. (So if a confirmation bubble and a notification bubble are visible simultaneously, there should 0.5 em gap between them.)
  3. Notification bubbles should use the top right corner: the top of a notification bubble should be 0.5 em from the top of the display (or from the bottom of any panels at the top of the display). Confirmation bubbles should use the bottom right corner: the bottom of a confirmation bubble should be 0.5 em from the bottom of the display (or from the top of any panels at the bottom of the display).

position-options.jpg

Bubble behavior

Animations and durations

Notification bubbles

Confirmation bubbles

Critical

Non-critical

When it appears

After all other pending critical notifications, before all non-critical ones.

After all other pending notification bubbles.

Replaces any earlier confirmation bubble immediately.

How it appears

Fades in over 200 ms if first in a series, or 300 ms if subsequent.

Fades in over 700 ms if first in a series, or 300 ms if subsequent.

Fades in over 100 ms.

Appears if screensaver inhibited

yes

no

yes

Standard duration

10000 ms + 250 ms/(line of body text)

5000 ms + 250 ms/(line of body text)

2000 ms

Extended by input

If between 1000 and 3000 ms there are any modifier keypresses or ≥10 non-modifier keypresses or ≥1 click, extend by 2000 ms. Very difficult to implement.

no

Extended by confirmation bubble appearing

Resets to previous duration, minus 1000 ms. This has no effect because it waits to leave at the same time as the confirmation bubble anyway.

n/a

Visible merging with enough room to show all body text

Over 250 ms, bubble grows initially linearly but decelerates as it reaches its new size; at the same time, if there was no body text previously, the title fades out (because it is about to appear in a new position). Then over another 250 ms (regardless of how much text is involved), the new text fades in; at the same time, the new icon (if any) cross-fades in.

n/a

Visible merging with overflow

Old text displays for bubble’s normal duration. Then over 250 ms (regardless of how much text is involved), text that will no longer appear in its current position scrolls up, with oldest text scrolling off the top and new text scrolling onto the bottom; at the same time, the new icon (if any) cross-fades in.

n/a

Extended by visible merging

+ 500 ms + 250 ms/(line of body text)

n/a

Visible replacement

Over 300 ms, the old contents fade out. Then over another 300 ms, the new contents fade in.

Changes instantly.

Extended by visible replacement

+ 2000 ms + 250 ms/(line of body text)

Resets.

Maximum duration

15000 ms (overriding all the above)

How it disappears

Over 300 ms, fades out.

If a bubble is replaced with one that has the same icon and the same title text, and the new body text is an extension of the old body text, this should not be presented as a normal replacement; instead the bubble should be presented as if the old and new bubbles were being merged.

If a pointer is over the area where a bubble is about to appear, it should appear as normal, ignoring the pointer unless it leaves and then re-enters the area. In all other cases where a pointer is over a bubble, however, the bubble’s duration should pause until the pointer leaves. For example, if a notification bubble has been fully visible for 2000 ms when a pointer enters, it should switch to its mouseover appearance until the pointer leaves, then switch back to its normal appearance and display for a further 3000 ms.

If the only bubble on a display is fading out when another bubble would appear below it, the newer bubble must instead wait until the older one has completed fading out.

Sound

If a notification bubble has a sound associated with it, that sound should be played starting from the moment the bubble has finished fading in.

Merging notifications

Notify OSD should merge two notifications into a single notification if all of the following are true:

When merging notifications, the icon and sound (if any) of the latter notification should be used. The body text of the latter should be appended to the body text of the former, with a line break inserted between them if there was none already. For example, if the notification in queue position 4 has title “andrew_p” and body text “Hey Coral”, while the notification in queue position 7 has the same icon and title “andrew_p” and body text “Are you still in Oregon?”, then the body text of the notification at position 4 should be changed to
  Hey Coral
  Are you still in Oregon?
and the notification at position 7 should be deleted from the queue.

If the earlier bubble is already being displayed and not yet in the process of fading out, the bubble contents should be changed as described above.

Overflow of long messages

notification-text-overflow.jpg

If a bubble’s body text — either initial, or after merging — would take up more than ten lines inside the bubble, the body text should be presented as:

  1. the first line of text;
  2. an ellipsis (…) on a line by itself;
  3. the last eight lines of text.

The transition from the non-overflow presentation to the overflow presentation, i.e. the arrival of an eleventh line of text, should be:

Flood prevention

A notification should be discarded from the queue if there are more than 50 notifications ahead of it in the queue.

Furthermore, a notification should be discarded from the queue if, after any merging, there are more than ten notifications from the same program (as identified by its D-Bus ID) before it in the queue.

“Do not disturb” mode

Applications should be able to send a signal to gnome-session — in the same way that they can currently inhibit logout, account switching, suspending, or screensaver — to inhibit non-critical notifications.

<doc:item>
  <doc:term>16</doc:term>
  <doc:definition>Inhibit non-critical notifications.</doc:definition>
</doc:item>

As a trial during Lucid, whenever an application inhibits notifications, Notify OSD should display a notification: “Further notifications have been disabled.”

Whenever non-critical notifications are being inhibited, they should be queued as normal, so that (subject to flood prevention) they can be displayed when the inhibition ends.

Fallback alert boxes

For cases where applications have expected the notification system to allow interactivity without checking whether it actually does, and cases where applications have expected the notification system to display a notification indefinitely, Notify OSD should show an alert box as a fallback. The alert box should appear centered on whichever display the first pointer is on at the moment it is due to appear. Because they require a response but should not block the queue, multiple alert boxes may be open at once.

An alert has custom text and buttons. The title of the alert should be the name of the process that is invoking the notification. The icon should always be the Warning /!\ dialog-warning icon. The text should be presented uniformly in the standard application font size.

fallback-alert.jpg

The first button should be positioned in the bottom right corner of the alert. Immediately to its leading side should be a “Cancel” button that has no action. Any other buttons should be positioned from leading side to trailing side, starting at the bottom leading corner of the alert. None of the buttons should be set as the default (because the system can’t detect that any of them are safe as a default).

Activating any button should close the alert, and then perform the associated action if any.

Logging notifications

For debugging and anorak purposes, each notification (but not each confirmation bubble) should be logged in the file “$HOME/.cache/notify-osd.log” (bug 332950). The log should take this form:

[timestamp, process-name] title
body
body
body

[timestamp, process-name, appended] title
body
body
body

[timestamp, process-name, replaced] title
body
body
body

The timestamp should be in the format defined by RFC 3339.

The log should be cleared whenever you log out or log in.

(Note: logging to this file is enabled when the LOG environment variable is set to 1.)

Critical and non-critical queues and do-not-disturb mode

Every notification, whether it is to be presented as a bubble or as a fallback alert box, should be treated as if it is in one of two queues: critical or non-critical. All pending critical notifications should appear before any pending non-critical notification bubbles appear; and within each queue, notifications should appear in chronological order. (This means, for example, that a fallback alert box should not appear until earlier notification bubbles have finished displaying. This prevents a later interactive notification from appearing inappropriately before an earlier non-interactive one from the same program.)

Whenever a program is inhibiting the screensaver, Notify OSD should be in do-not-disturb mode. While in this mode:

When Notify OSD leaves do-not-disturb mode, normal processing of the non-critical notification queue should resume.

Treatment of the Desktop Notifications Specification 1.1

Notify OSD should function as an implementation of the Desktop Notifications Specification 1.1, as follows.

org.freedesktop.Notifications.GetCapabilities

The system should return the capabilities {"body", "body-markup", "icon-static", "x-canonical-append", "x-canonical-truncation"}. (For why it should return "body-markup", see “Sanitizing body text”.)

org.freedesktop.Notifications.Notify

If actions is supplied and/or expire_timeout is set to “0”, the notification should be presented as a fallback alert box:

In all other cases, the notification should be presented as a bubble:

Sanitizing body text

The Desktop Notification Specification states that “Body text may contain markup. The markup is XML-based, and consists of a small subset of HTML along with a few additional tags … Notification servers that do not support these tags should filter them out.”

Unfortunately, the specification does not state explicitly whether body text may contain markup if the server does not return the capability “body-markup”. And even if that was not allowed, notification-daemon supports markup, so many programs use it without first checking whether the server supports it. The specification also does not specify how clients should transmit < or > characters that are not intended to be interpreted as HTML tags. And if this is supposed to be done using character references, the specification also does not specify whether character references should be recognized for all characters, or just for <, >, and &. This leaves us in a situation similar to RSS 2.0: “Here’s something that might be HTML. Or maybe not. I can’t tell you, and you can’t guess.”

Meanwhile, notification-daemon uses Pango markup directly, which means it interprets not only the markup defined in the Desktop Notification Specification, but also the extra elements and attributes recognized by Pango.

Because it would be extremely difficult to find and fix all programs that use markup without checking (much more difficult than finding and fixing those that use actions without checking), Notify OSD must instead accept markup and ignore it. This in turn means that it must advertise that it accepts markup ("body-markup") — even though this markup has no effect on the bubble text — so that clients can deduce that they need to escape non-markup <, >, and & characters.

To provide a reasonable amount of compatibility until the Desktop Notification Specification is revised to be more precise, Notify OSD should try to guess whether < > and & characters are being used as plain text or HTML, as follows:

  1. If the text contains a < character that is immediately followed by a letter or by a / character, and a > character occurs later in the string, the sequence from that < character to the soonest-following > character inclusive should be treated as an HTML tag and removed. Repeat for all such remaining sequences. All other < and > characters should be assumed to be literal. Then:

  2. If the text contains a “&” character, and a “;” character occurs later in the string, the sequence from that “&” character to the soonest-following “;” character should be presented as follows:

    String

    Presented as

    &amp;

    &

    &#38;

    &

    &#x26;

    &

    &lt;

    <

    &#60;

    <

    &#x3C;

    <

    &#x3c;

    <

    &gt;

    >

    &#62;

    >

    &#x3E;

    >

    &#x3e;

    >

    &apos;

    '

    &quot;

    "

    anything else

    unaltered

    Repeat for all such remaining sequences. All other & characters should be assumed to be literal.

This Desktop-Notification-Specification-specific sanitizing should happen before the normal whitespace filtering for body text.

Applications should be highly encouraged to escape “<”, “>”, and “&” characters (e.g. as “&lt;”, “gt;”, and “&amp;” respectively) in text they receive from external sources (such as instant messages or song metadata).

org.freedesktop.Notifications.CloseNotification

The relevant notification should disappear immediately, without fading out.

org.freedesktop.Notifications.GetServerInformation

The system should return out_name = “Notify OSD”, out_vendor = “Canonical Ltd”, out_version = “1.0”, and out_spec_ver = “0.9”.

org.freedesktop.Notifications.NotificationClosed

Should be implemented as specified.

org.freedesktop.Notifications.ActionInvoked

This signal should never be emitted.

Treatment of the KNotification API

Notify OSD should function as an implementation of the KNotification class (but not the previous KNotify class).

The API should let applications know whether the notification system allows actions.

Treatment of hotkeys

Volume changes

Now covered in the Sound specification.

Brightness and backlight changes

brightness.jpg

When you change the display’s or keyboard backlight’s brightness using keyboard hotkeys, the change in brightness should be shown in a confirmation bubble with a gauge. To make clearer which key was pressed, if the bubble was not already open, the gauge should show the old value for half a second before switching to the new value. If you press the reduce-brightness key when the volume is already at zero, or the increase-brightness key when the volume is already at maximum, the icon and gauge should flash.

Visually, the bubble should not contain any text. But for accessibility purposes, the bubble should expose title text of the form “Brightness: 60 percent” or “Backlight brightness: 20 percent”, as appropriate.

Disc ejection

eject.jpg

When you press the EJECT_KEY, a confirmation bubble should appear containing only the eject icon. Implementation: Issue a notification using the “x-canonical-private-icon-only” and “x-canonical-private-synchronous” hints.

Visually, the bubble should not contain any text. But for accessibility purposes, the bubble should expose the title text “Eject”.

Play, Pause, Stop, Previous, and Next

When you press the PLAY_KEY, PAUSE_KEY, STOP_KEY, PREVIOUS_KEY, or NEXT_KEY, a confirmation bubble should appear containing only the icon for that function. Implementation: Issue a notification using the “x-canonical-private-icon-only” and “x-canonical-private-synchronous” hints.

Visually, the bubble should not contain any text. But for accessibility purposes, the bubble should expose the title text “Play”, “Pause”, “Stop”, “Previous”, or “Next” as appropriate.

Treatment of hardware device detection

device-connected.jpg

When a device is connected, a confirmation bubble should appear immediately, with a generic USB, Firewire, or miscellaneous (e.g. eSATA) device icon, title text “Device connected”, and no body text.

A further confirmation bubble should not appear when the device is fully identified.

Architecture

Relationships with external modules: (SVG source)

NotificationSystemCommunication.png

(See also a detailed description of components involved in hardware hotkeys.)

Overview of internal modules: (SVG source)

NotificationSystemLayers.png

Details of the visual layer: (SVG source)

NotificationManager-Design-2.png

Compatibility fixes accepted upstream

Ubuntu and upstream developers have made fixes to several programs to make their notifications compatible with Notify OSD and the Desktop Notifications Specification. For designs of fixes that are now incorporated into the upstream projects, see PreviousCompatibilityFixes.

Compatibility fixes still to be maintained

Other compatibility fixes have not yet been implemented, or have been implemented in Ubuntu packages but not yet merged upstream. These fixes are listed in this specification, alphabetically by package name, to assist in regression testing.

If you’re the application developer or someone who can patch one of these programs, see NotificationDevelopmentGuidelines for guidelines and code samples.

Once a fix has been accepted upstream, please move its specification from this document to PreviousCompatibilityFixes.

amsn

apport

banshee

bluez-gnome

bluez-pairing-before.png

bzr-gtk

debian-bts-applet

decibel-audio-player

Launchpad #328609

emesene

empathy

When you receive a message from someone:

No notification bubble should be added or changed because someone is typing.

evolution

Launchpad #331571

firefox

firefox-current.png

Firefox uses custom notification boxes that do one thing when clicked. We are working with Mozilla on ways to present these without using a custom notification system.

* An experimental plugin for integrating Firefox with libnotify can be downloaded from here https://addons.mozilla.org/en-US/firefox/addon/9622 or as an Ubuntu Package from here http://packages.ubuntu.com/karmic/firefox-notify (karmic)

gajim

Giver

gmail-notify

gnome-disk-utility

gnome-mount-unmounting.png

gnome-power-manager

Gnome Power Manager puts up interactive notifications in many situations (bug 329296).

Five of these are unusual and important and should be acknowledged, so they should be presented as alert boxes instead:

Implementation: Tweak gpm-notify.c so that it uses the #else versions of the #ifdef HAVE_LIBNOTIFY functions. The design of these alerts could be improved, but we should not spend time on this now, because the code will soon be replaced by DeviceKit-power. Once DeviceKit-power is being used, the “Power Critically Low” alert should be reimplemented as a morphing alert box.

Two others should put up neither a notification bubble nor an alert, so their bubbles should be removed:

And one should be changed to be more useful (bug 399492):

gnome-screensaver

while-you-were-out.jpg

gnome-settings-daemon

gnome-user-share

gnoemoe

goobox

gossip

#328613

gshutdown

kerneloops

kopete

kpackagekit

kwalletmanager

liferea

Launchpad #328606

network-manager

Because Network Manager is a high-profile user of notification bubbles, it should be adjusted not just for compatibility with Notify OSD, but also to make its bubbles more elegant regardless of which notification system is in use.

wireless-connected.jpg

3g-detected.png

3g-finished.png

ontv

openoffice.org-impress

Impress should have a checkmark item in its “Slide Show” menu for whether non-critical notifications are suppressed during a slide show.

impress-before.png

impress-after.jpg

packagekit-gnome

?

pidgin

pidgin-libnotify-capture.png

In addition, Pidgin should be integrated with the messaging menu.

powerdevil

quassel

software-sources

The “Updates” settings in Software Sources should be modified to reflect the automatic-opening behavior.

specto

specto is fixed in 0.3 development branch http://code.google.com/p/specto/issues/detail?id=215

system-config-printer

https://bugs.edge.launchpad.net/ubuntu/+source/system-config-printer/+bug/328604 - patch submitted

system-install-packages

thunderbird

timer-applet

totem

In its “Display” preferences, Totem should have a checkbox for whether full-screen movies suppress non-urgent notifications.

totem-preferences-before.png

totem-preferences-after.jpg

tracker

(bug 350415)

tracker-before.png

vlc

Launchpad #328605

zeroinstall

Zero Install uses a notification with a download button when updates are available. Debian/testing has a fixed version - please sync from there. See https://bugs.launchpad.net/ubuntu/+source/zeroinstall-injector/+bug/336317

Orage

Mail Notification

mail-notification.png

When new mail arrives, Mail Notification notifies you in a variety of ways, some of which are not relevant to or appropriate for Notify OSD (bug 332767):

cGmail

(bug 335197)

MeMaker

pastebin plasma widget

Lancelot

"Lancelot is a program launcher menu for KDE 4 designed to provide a place from which all your jobs begin. It provides quick access to applications, places, documents, contacts and system information." -- from the project web site

Phonon

How you can help: Write here what package this is.

Release notes

Unresolved issues

NotifyOSD (last edited 2014-04-02 11:35:47 by mpt)