1 |
TODO |
2 |
---- |
3 |
|
4 |
* Command for executing new programs. |
5 |
|
6 |
* Commands for changing z order and focus. |
7 |
|
8 |
* Command for transferring icon. |
9 |
|
10 |
* Think about protocol version management |
11 |
|
12 |
* Try to assure that messages aren't repeated or are sent for hidden windows. |
13 |
|
14 |
Overview |
15 |
======== |
16 |
|
17 |
The protocol is a line based protocol following this simple syntax: |
18 |
|
19 |
OPERATION[,ARG1[,ARG2,[...]]] |
20 |
|
21 |
The goal is to have a generic protocol that can be used for other display |
22 |
systems (e.g. VNC) as well. |
23 |
|
24 |
One line may not exceed 1024 bytes, including newline. |
25 |
|
26 |
The protocol has no concept of hidden or unmapped windows. A window does not |
27 |
exist unless it is visible. Note that a minimised window is an exception to |
28 |
this rule. |
29 |
|
30 |
Data types |
31 |
========== |
32 |
Window ID are written in hex, like 0x4321. |
33 |
|
34 |
Window positions can be negative. This happens when a window is moved |
35 |
outside the desktop. |
36 |
|
37 |
All integers fit inside 32 bits. |
38 |
|
39 |
Server to Client Operations |
40 |
=========================== |
41 |
|
42 |
CREATE1 |
43 |
------- |
44 |
|
45 |
Allocate structures for a new window. |
46 |
|
47 |
Syntax: |
48 |
CREATE1,<ID>,<FLAGS> |
49 |
|
50 |
Note that very little information is included in this message. Things like |
51 |
title and state will come in subsequent messages. This message should only |
52 |
be used to allocate data structures for the new window. |
53 |
|
54 |
DESTROY1 |
55 |
-------- |
56 |
|
57 |
Remove a window. |
58 |
|
59 |
Syntax: |
60 |
DESTROY1,<ID>,<FLAGS> |
61 |
|
62 |
Remove the window and deallocate all associated structures. |
63 |
|
64 |
POSITION1 |
65 |
--------- |
66 |
|
67 |
Move a window. |
68 |
|
69 |
Syntax: |
70 |
POSITION1,<ID>,<X>,<Y>,<WIDTH>,<HEIGHT>,<FLAGS> |
71 |
|
72 |
Move and/or resize a window. If the window isn't visible yet (because a |
73 |
SETSTATE1 hasn't been set or because it's minimised), you must store the |
74 |
position and size. A new POSITION1 is not guaranteed to be sent when the |
75 |
window changes state. |
76 |
|
77 |
|
78 |
ZCHANGE1 |
79 |
-------- |
80 |
|
81 |
The window moved in z order. |
82 |
|
83 |
Syntax: |
84 |
ZCHANGE1,<ID>,<BEHIND>,<FLAGS> |
85 |
|
86 |
The window with the id ID is behind the window with the id BEHIND. If |
87 |
BEHIND is 0, then this window should be brought to the front. |
88 |
|
89 |
SETSTATE1 |
90 |
--------- |
91 |
|
92 |
Changes the window's state and/or title. |
93 |
|
94 |
Syntax: |
95 |
SETSTATE1,<ID>,<TITLE>,<STATE>,<FLAGS> |
96 |
|
97 |
State can have one of three values: |
98 |
0 : "Normal" window. |
99 |
1 : Minimised. |
100 |
2 : Maximised. |
101 |
|
102 |
|
103 |
DEBUG1 |
104 |
------ |
105 |
|
106 |
Debug output from the server component. |
107 |
|
108 |
Syntax: |
109 |
DEBUG1,<STRING> |
110 |
|
111 |
Used for debugging. |
112 |
|
113 |
SYNCBEGIN |
114 |
--------- |
115 |
|
116 |
Indicates that a synchronisation has begun. |
117 |
|
118 |
Syntax: |
119 |
SYNCBEGIN,<FLAGS> |
120 |
|
121 |
Sent when the server starts a synchronisation. The client should flush all |
122 |
information at this point. |
123 |
|
124 |
SYNCEND |
125 |
------- |
126 |
|
127 |
Indicates that a synchronisation is complete. |
128 |
|
129 |
Syntac: |
130 |
SYNCEND,<FLAGS> |
131 |
|
132 |
Sent when the last message that is part of the synchronisation has been sent. |
133 |
This may be followed by duplicate messages and/or messages referring invalid |
134 |
windows that were queued up during the synchronisation. |
135 |
|
136 |
Client to Server Operations |
137 |
=========================== |
138 |
|
139 |
SYNC |
140 |
---- |
141 |
|
142 |
Request a synchronisation of window information. |
143 |
|
144 |
Syntax: |
145 |
SYNC,<FLAGS> |
146 |
|
147 |
For each window, the server will send CREATE1, POSITION1 and SETSTATE1 just as |
148 |
if the window was created. |