diff options
| author | Mike Hearn <mike@navi.cx> | 2004-07-01 23:03:12 +0000 |
|---|---|---|
| committer | Mike Hearn <mike@navi.cx> | 2004-07-01 23:03:12 +0000 |
| commit | a0897d845141a9d1963ef82e53e4f32be82739ad (patch) | |
| tree | b77542982113ca41b7801542c4e580b727982102 /SPECIFICATION | |
| parent | 203f183810dcf1f876fdb4755c62f3f634b673f6 (diff) | |
| download | libnotify-a0897d845141a9d1963ef82e53e4f32be82739ad.tar.gz | |
rename CapsQuery to GetCapabilities
Diffstat (limited to 'SPECIFICATION')
| -rw-r--r-- | SPECIFICATION | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/SPECIFICATION b/SPECIFICATION index 455fd17..2ad0ed6 100644 --- a/SPECIFICATION +++ b/SPECIFICATION @@ -74,7 +74,7 @@ A notification has the following components: - An array of actions. The actions send a request message back to the notification client when invoked. This functionality may not be implemented by the notification server, conforming clients should - check if it is available before using it (see the CapsQuery message + check if it is available before using it (see the GetCapabilities message in the PROTOCOL section). An implementation is free to ignore any requested by the client. As an example one possible rendering of actions would be as buttons in the notification popup. @@ -107,7 +107,7 @@ assumptions about the presentation and abilities of the notification server: the message content is the most important thing. Clients can check with the server what capabilities are supported -using the CapsQuery message. See the PROTOCOL section. +using the GetCapabilities message. See the PROTOCOL section. If a client requires a response from a passive popup, it should be coded such that a non-focus-stealing message box can be used instead @@ -165,7 +165,7 @@ PROTOCOL The following messages must be supported by all implementations. -* CapsQuery +* GetCapabilities This message takes no parameters. |