blob: 7d497c93cb089cdcf577202dc9dbfdc6e735d92b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
FreeDesktop proposed notifications spec
=======================================
(c) 2004 Mike Hearn <mike@navi.cx>
2004 Christian Hammond <chipx86@chipx86.com>
ChangeLog:
v0.1:
* Initial version
---------------------------------------------------------------------
OVERVIEW
This is a draft standard for a desktop notifications service, through
which applications can generate passive popups (sometimes known as
"poptarts") to notify the user in an asynchronous manner of events.
This specification explicitly does not include other types of
notification presentation such as modal message boxes, window manager
decorations or window list annotations.
Example use cases include:
* Presence changes in IM programs: for instance, MSN Messenger on
Windows pioneered the use of passive popups to indicate presence
changes.
* New mail notification
* Low disk space/battery warnings
BASIC DESIGN
In order to ensure that multiple notifications can easily be
displayed at once, and to provide a convenient implementation, all
notifications are controlled by a single session-scoped service which
exposes a DBUS interface.
On startup, a conforming implementation should take the
"org.freedesktop.Notifications" service on the session bus. This
service will be referred to as the "notification server" or just "the
server" in this document. It can optionally be activated automatically
by the bus process, however this is not required and notification
server clients must not assume that it is available.
The server should implement the "org.freedesktop.Notifications" interface on
an object with the path "/org/freedesktop/Notifications". This is the
only interface required by this version of the specification.
A notification has the following components:
- A summary: This is a single line overview of the notification. For
instance "You have mail" or "A friend has come online". It should
generally not be longer than 40 characters (FIXME: is 40 sane?)
- An optional body: This is a multi-line body of text. Each line is a
paragraph, server implementations are free to word wrap them as they
see fit.
The text may contain simple markup as specified in the MARKUP
section below.
If the body is omitted just the summary is displayed.
- An optional icon: See the ICONS/SOUNDS section below.
- An optional sound: See the ICONS/SOUNDS section below.
- An array of buttons. The buttons send a request message back to the
notification client when clicked.
- A timeout: the time in milliseconds after which the notification
should be hidden (FIXME: should this be a function of text length
to accommodate different reading speeds?). If zero the notification
stays on-screen indefinitely (persistent notifications).
The timeout should be respected by implementations, but this is not
required (this is for compatibility with KNotify).
Each notification displayed is allocated a unique ID by the server
(FIXME: should this be unique within a session, or just unique while
the notification is active?). This can be used to hide the
notification before the timeout is over. It can also be used to
atomically replace the notification with another: this allows you to
(for instance) modify the contents of a notification while it's
on-screen.
BACKWARDS COMPATIBILITY
Prior art in this area is basically just the KNotify system. This
specification strives to be compatible with KNotify, however there is
still some semantic mismatch. Clients should try and avoid making
assumptions about the presentation and abilities of the notification
server: the message content is the most important thing.
MARKUP
Write me!
ICON ENCODING
Write me!
DBUS PROTOCOL
Write me!
|
