Fixed to actually be valid docbook.
This commit is contained in:
parent
2aabd35c72
commit
47cde24c15
|
@ -1,3 +1,8 @@
|
||||||
|
Wed Jan 25 23:45:11 PST 2006 Christian Hammond <chipx86@chipx86.com>
|
||||||
|
|
||||||
|
* notification-spec.xml:
|
||||||
|
- Fixed to actually be valid docbook.
|
||||||
|
|
||||||
Mon Jan 23 01:18:23 PST 2006 Christian Hammond <chipx86@chipx86.com>
|
Mon Jan 23 01:18:23 PST 2006 Christian Hammond <chipx86@chipx86.com>
|
||||||
|
|
||||||
* notification-spec.xml:
|
* notification-spec.xml:
|
||||||
|
|
|
@ -220,54 +220,60 @@
|
||||||
<row>
|
<row>
|
||||||
<entry>Actions</entry>
|
<entry>Actions</entry>
|
||||||
<entry>
|
<entry>
|
||||||
The actions send a request message back to the notification client
|
<para>
|
||||||
when invoked. This functionality may not be implemented by the
|
The actions send a request message back to the notification client
|
||||||
notification server, conforming clients should check if it is available
|
when invoked. This functionality may not be implemented by the
|
||||||
before using it (see the GetCapabilities message in
|
notification server, conforming clients should check if it is available
|
||||||
<xref linkend="protocol"/>). An implementation is free to ignore any
|
before using it (see the GetCapabilities message in
|
||||||
requested by the client. As an example one possible rendering of
|
<xref linkend="protocol"/>). An implementation is free to ignore any
|
||||||
actions would be as buttons in the notification popup.
|
requested by the client. As an example one possible rendering of
|
||||||
|
actions would be as buttons in the notification popup.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Actions are sent over as a list of pairs. Each even element in the
|
||||||
|
list (starting at index 0) represents the identifier for the action.
|
||||||
|
Each odd element in the list is the localized string that will be
|
||||||
|
displayed to the user.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The default action (usually invoked my clicking the notification)
|
||||||
|
should have a key named <literal>"default"</literal>. The name can
|
||||||
|
be anything, though implementations are free not to display it.
|
||||||
|
</para>
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
|
||||||
Actions are sent over as a list of pairs. Each even element in the
|
|
||||||
list (starting at index 0) represents the identifier for the action.
|
|
||||||
Each odd element in the list is the localized string that will be
|
|
||||||
displayed to the user.
|
|
||||||
</entry>
|
|
||||||
<entry>
|
|
||||||
The default action (usually invoked my clicking the notification)
|
|
||||||
should have a key named <literal>"default"</literal>. The name can
|
|
||||||
be anything, though implementations are free not to display it.
|
|
||||||
<entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>Hints</entry>
|
<entry>Hints</entry>
|
||||||
<entry><para>See <xref linkend="hints"/>.</para></entry>
|
<entry>
|
||||||
|
<para>See <xref linkend="hints"/>.</para>
|
||||||
<para>
|
<para>
|
||||||
Beyond the core protocol is the hints table. A couple of core
|
Beyond the core protocol is the hints table. A couple of core
|
||||||
elements have been moved to hints mostly because in a huge number
|
elements have been moved to hints mostly because in a huge number
|
||||||
of cases their default values would be sufficent. The elements moved
|
of cases their default values would be sufficent. The elements moved
|
||||||
to hints are:
|
to hints are:
|
||||||
</para>
|
</para>
|
||||||
<segmentedlist>
|
<segmentedlist>
|
||||||
<seglistitem>
|
<title>Elements Moved to Hints</title>
|
||||||
<seg>Category ID</seg>
|
<segtitle>Element</segtitle>
|
||||||
<seg>An optional ID representing the type of notification (the name
|
<segtitle>Description</segtitle>
|
||||||
has been changed from Notification Type ID in pervious versions).
|
<seglistitem>
|
||||||
See <xref linkend="categories"/>.</seg>
|
<seg>Category ID</seg>
|
||||||
</seglistitem>
|
<seg>An optional ID representing the type of notification (the name
|
||||||
<seglistitem>
|
has been changed from Notification Type ID in pervious versions).
|
||||||
<seg>Urgency Level</seg>
|
See <xref linkend="categories"/>.</seg>
|
||||||
<seg>The urgency of the notification. See
|
</seglistitem>
|
||||||
<xref linkend="urgency-levels"/>. (Defaults to 1 - Normal)</seg>
|
<seglistitem>
|
||||||
</seglistitem>
|
<seg>Urgency Level</seg>
|
||||||
<seglistitem>
|
<seg>The urgency of the notification. See
|
||||||
<seg>Icon Data</seg>
|
<xref linkend="urgency-levels"/>. (Defaults to 1 - Normal)</seg>
|
||||||
<seg>Instead of overloading the icon field we now have an icon_data
|
</seglistitem>
|
||||||
field that is used when icon is blank.</seg>
|
<seglistitem>
|
||||||
</seglistitem>
|
<seg>Icon Data</seg>
|
||||||
</segmentedlist>
|
<seg>Instead of overloading the icon field we now have an icon_data
|
||||||
|
field that is used when icon is blank.</seg>
|
||||||
|
</seglistitem>
|
||||||
|
</segmentedlist>
|
||||||
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>Expiration Timeout</entry>
|
<entry>Expiration Timeout</entry>
|
||||||
|
@ -720,8 +726,8 @@
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>"desktop-entry"></literal></entry>b
|
<entry><literal>"desktop-entry"></literal></entry>
|
||||||
<entry>Application Desktop ID</entry>
|
<entry>string</entry>
|
||||||
<entry>
|
<entry>
|
||||||
This specifies the name of the desktop filename representing the
|
This specifies the name of the desktop filename representing the
|
||||||
calling program. This should be the same as the prefix used for the
|
calling program. This should be the same as the prefix used for the
|
||||||
|
|
Loading…
Reference in New Issue