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
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
|
Help about twin configuration
First, you might want to edit the files `makerules' and `makeautoconf.in' to
change the install directory, tweak compiler flags (enable debugging), etc.
If you are trying to compile on non-Linux systems, you would do better
reading the file README.porting now, for useful tips and warnings.
Then type `./configure' to configure twin for your system.
Finally, type `make'.
Automatic configuration of twin basically reduces to the above.
If you are one of the geeks that want to configure twin manually,
keep reading.
WARNING:
WARNING: MANUALLY CONFIGURING TWIN IS ALMOST ALWAYS UNNECESSARY
WARNING: AND WILL VERY EASILY RESULT IN `make' BOMBING OUT WITH ERRORS!
WARNING:
WARNING: DON'T ASK FOR HELP AFTER YOU CONFIGURED TWIN MANUALLY:
WARNING: YOUR FEEBLE CRIES WILL BE IGNORED!
WARNING:
WARNING: STOP READING NOW!
WARNING:
Since you are still reading, from now on I'll assume you know
what you are doing.
To manually configure twin, you can:
* edit conf/conf.auto, possibly using conf/conf.default as template;
* run `make config': a shell script asking a lot of questions will start;
* run `make menuconfig': a somewhat more friendly interface will be started
(requires a fairly recent `dialog' utility);
* run `./configure [OPTIONS]': this will automatically disable features that
are unavailable on your system, and will enable by default all other
(available) features.
* run `scripts/Configure [OPTIONS]': lets you manually change each and every
configuration option, defaulting to current ones.
Note that this lets you set inconsistent options: for example
`scripts/Configure --disable--modules --enable-wm=socket' tries to disable
modules and at the same time to enable the window manager as module.
Provided Makefiles are smart enough to realize this risk and automatically
regularize the configuration before starting to compile, so it may happen
than `scripts/Configure --show' report different configurations before and
after compiling: the latter comes from regularizing the former.
If you want, you can regularize manually with 'make nullconfig'.
Also, to ensure the configuration you choosed does not use features
unavailable on your system, you can process it with `./configure';
this is very easy: just type (including the backquotes)
./configure `scripts/Configure --show`
In the first case, you will have to figure out by your own what the various
variables mean (tip: look at the CONF_* lines below).
In the last two cases, you also need to know that each
--enable-feature corresponds to the CONF_FEATURE with the same name
(except for prefix and upper/lower case); for example,
--enable-wm-rc corresponds to CONF_WM_RC.
In the remaining cases (`make config' and `make menuconfig'), the questions
asked are the same:
First question:
#
# General setup
#
(CONF__SHLIBS)
Enable shared libraries (ELF) [Y/n] ?
Answer `y' if you want to compile shared libraries
(libTw.so, the library used by clients to talk to twin, and some others)
This works only if you have an ELF system.
If you say 'n' only the static version of the libraries will be compiled.
(CONF__MODULES)
Enable modules (ELF) [y/N] ?
Answer `y' if you want to be able to use modules (= code which can be
inserted and removed from a running twin whenever you want).
This works only if you have ELF-compatible dlopen().
(CONF__MALLOC)
Use custom malloc/free routines (tested on Linux/i386 only) [y/N] ?
Answer 'y' to use home-made, mmap() based replacements of malloc/free.
Their main (only) advantage is they are very clever in returning
unused memory to the system. Anyway, they are tested only on Linux/i386,
and furthermore they shoot heavily on the kernel mmap() subsystem,
so on some OSes they may give troubles.
(CONF__UNICODE)
Build all code with Unicode support [Y/n] ?
Answer 'y' unless you know what you are doing. Saying 'n' skips compiling
all necessary code to support Unicode, and produced clients and libraries
will be *incompatible* with ones built with Unicode support. Also, mixing
Unicode aware clients with a non-Unicode server or vice-versa may result
in non-ASCII characters being rendered wrongly. It makes sense to say 'n'
only if you have extremely tight memory requirements.
#
# Socket support
#
(CONF_SOCKET)
Support remote socket connections [Y/m/n] ?
Answer `y' or `m' if you want to be able to run external client programs.
Answer `n' only if you _really_ know what you are doing.
(CONF_SOCKET_GZ)
-> Sockets: Support gzip compression [Y/n] ?
Answer `y' if you want to enable transparent gzip compression in the
socket connections. This requires having zlib installed.
Read paragraph `7. Transparent Compression' of the Tutorial for details.
(CONF_SOCKET_PTHREADS)
-> Sockets: thread-safe libraries (requires pthread.h) [Y/n] ?
Answer `y' if you want libraries (libTw, libTutf, libTT) to be thread-safe.
You need pthread.h and libpthread for this to work.
(CONF_SOCKET_ALIEN)
-> Sockets: support non-native architectures [Y/n] ?
Answer `y' if you want clients with different data sizes / endianity
to be able to connect to the server. In short, this adds server-side
32<->64 bit and little<->big endian translations, letting server talk
with clients running on different architectures than the server.
(CONF_WM)
Builtin Window Manager: absolutely needed! [Y/m/n] ?
This is to compile the window manager separately from twin core.
Twin will not work without the window manager. Just say `y' or 'm'.
(CONF_WM_RC)
WM: Support ~/.twinrc configuration parser [y/m/N] ?
Answer 'y' or 'm' to allow customization of the window manager look-n-feel
using the configuration file ~/.twinrc. For the syntax of the file look
at the sample configuration 'system.twinrc' distributed with twin.
Since the RC parser is quite big and is used only at startup, it would be
a good idea to say 'm' here (if you enabled modules) rather than 'y'.
(CONF_WM_RC_SHMMAP)
-> WM: Use mmapped shared file to parse ~/.twinrc [y/N] ?
This is mostly a matter of taste. In order to safely parse ~/.twinrc,
twin forks() a child process that does the dirty work, then collects
the result. If you say 'n', the child will send the result to parent
through a socket, while if you say 'y' communication will use a
shared memory area coming from a mmapped file in /tmp.
As a rule of thumb, say 'n' unless you also enabled "custom malloc/free".
(CONF_WM_RC_SHRINK)
-> WM: RC: shrink memory when parser finished [Y/n] ?
This is a good thing, answer 'y' unless twin explicitly reported
it does not work.
For those who want an explanation: the parser tries to guess how much
memory it will need to parse ~/.twinrc and allocates it beforehand.
To be on the safe side, the allocated memory size is a worst-case guess
and it is quite high (about 10 times the size of your ~/.twinrc).
If you did not enable CONF_WM_RC_SHMMAP above (which has a safe replacement
for this), and answer 'y' here, the parser tries to realloc() that memory
once it has finished, to free the part in excess.
Depending on your OS, realloc() may move that memory to a new location,
making it unusable since it contains a lot of pointers.
If this ever happens, twin will report the error and tell you to disable
the option.
#
# Terminal emulator
#
(CONF_TERM)
Builtin Terminal emulator [Y/m/n] ?
Answer `y' or `m' if you want to compile the terminal emulator
built-in into twin. This code is also necessary to run `twterm',
the external terminal emulator,
so answer `n' only if you _really_ know what you are doing.
(CONF_TERM_DEVPTS)
-> Terminal: use glibc-2.1 /dev/pts/ [y/N] ?
Answer `y' if you are compiling twin with glibc-2.1 or later and you
want to use /dev/pts/* terminals instead of old-style /dev/tty[p-z]*.
#
# Messages logging
#
(CONF_PRINTK)
Store server messages into Messages window [Y/n] ?
Answer `y' to get a copy of twin diagnostic messages in the
Messages window (you can open it from the default menu).
Just say `y'.
#
# Display hardware support
#
(CONF_HW_TTY)
HW support: textmode terminals (Linux console, ...) [Y/m/n] ?
Answer `y' or 'm' if you are interested in running twin
on text terminals (ttys). You will be asked further questions
to choose exactly which ttys you want support for.
(CONF_HW_TTY_LINUX)
-> tty support: Linux console [Y/n] ?
Answer 'y' if you are compiling under Linux and you are interested
in running twin on the Linux console.
(CONF_HW_TTY_TWTERM)
-> tty support: Twin terminal [Y/n] ?
Answer 'y' if you are interested in running twin inside
a twin terminal emulator (i.e. a shell window inside another twin).
(CONF_HW_TTY_TERMCAP)
-> tty support: termcap/ncurses terminal database [Y/n] ?
Answer 'y' if you want twin to be able to display on any termcap-compatible
terminal. This includes almost any existing terminal, but is far from
optimal and may give problems with some keys (function keys, arrows, etc.).
(CONF_HW_X11)
HW support: X11 [Y/m/n] ?
Answer 'y' or 'm' if you want twin to be able to display on X.
(CONF_HW_TWIN)
HW support: Twin, native [Y/m/n] ?
Answer `y' or 'm' to allow twin to connect to another twin
and open a window there as display.
(CONF_HW_DISPLAY)
HW support: twdisplay client as display [Y/m/n] ?
Answering `y' or `m' compiles `twdisplay', which can attach/detach displays
remotely. Answer `n' only if you know what you are doing.
(CONF_HW_GGI)
HW support: libggi [y/m/N] ?
Answer `y' or `m' to compile libggi display driver.
This is still incomplete, say `n'.
If you answer 'n' to both textmode terminals and X11 support,
you won't be able to do much with your shiny just compiled twin!
#
# Runtime options
#
(CONF_OPT_SHADOWS)
Runtime option: enable shadows [Y/n] ?
Answer 'y' if you want twin to draw shadows around each window.
This and all remaining answer allow you to adapt twin to your tastes.
No matter what you answer, you can always change the option while twin
is running from the `Options' dialog window. Please remember anyway that
the settings in ~/.twinrc will override these options.
(CONF_OPT_BLINK)
Runtime option: enable blink/high background [y/N] ?
Answer `y' to enable blinking/high background colors.
You can also change this option from the `Options' window inside twin.
(CONF_OPT_ALWAYSCURSOR)
Runtime option: cursor always visible [y/N] ?
Answer `y' to force the cursor to always be visible.
You can also change this option from the `Options' window.
(CONF_OPT_HIDEMENU)
Runtime option: hidden menu [y/N] ?
Answer `y' to keep the menu hidden when not active.
You can also change this option from the `Options' window inside twin.
(CONF_OPT_MENUINFO)
Runtime option: allow menu information row [Y/n] ?
Answer `y' to show client-specific information on the menu bar
when the menu is not active. If you answer `n', the menu will always
show the "normal" menu items.
You can also change this option from the `Options' window inside twin.
(CONF_OPT_EDGESCROLL)
Runtime option: enable screen scrolling [Y/n] ?
Answer `y' to enable virtual screen scrolling. If enabled, dragging
the mouse to one of the screen borders of twin will scroll the screen.
You can also change this option from the `Options' window inside twin.
|
