1 How to create a custom keyboard layout for Nokia internet tablets
2 =================================================================
4 1. Making a layout compiler
5 ---------------------------
7 First, you need to compile a compiler. You don't need the scratchbox (an
8 environment used for Maemo development) to do that - any Linux distribution
9 would do. For creating a .deb package the scratchbox is needed, though.
11 Simply unpack the ukeyboard package and run "make" in the ukeyboard
13 tar -xjf ukeyboard-VERSION.tar.bz2
16 (replace VERSION by the version you've downloaded)
18 2. Using the layout compiler
19 ----------------------------
21 Run vkb_compiler created in the previous step. As parameters, supply
22 a layout source file and name of the destination file. The name of the
23 destination file must have a .vkb extension.
24 ./vkb_compiler my_layout.def xx_XX.vkb
26 For rules for naming of destination files, see the section 4.1.
31 Make sure ukeyboard package is installed on the device. It does not have to
32 include your new layout.
34 Copy the compiled .vkb file to the /usr/share/ukeyboard/ directory on the
35 device. Ukeyboard will pick up the new layout automatically. Just go to
36 Text input settings in the Control panel and set your layout in the
39 If you update the .vkb file, just go to Text input settings again and
40 confirm the dialog without changing anything.
42 4. Limitation of the maemo keyboard layouts
43 -------------------------------------------
45 4.1 Allowed names of .vkb files
46 -------------------------------
48 The system limits the name of the compiled (.vkb) file in a way that it has
49 to match the name defined in the "lang" clause in the source (.def) file
50 (see section 6.2). You do not need to worry about that if you put your
51 layout into /usr/share/ukeyboard/, ukeyboard will do the necessary magic for
52 you. Just be sure the name of the file has the .vkb extension.
54 4.2 Allowed language codes
55 --------------------------
57 The name specified in the "lang" clause in the source file cannot be one of
58 da_DK, de_DE, el_GR, en_GB, en_US, es_ES, es_MX, fi_FI, fr_CA, fr_FR, it_IT,
59 nl_NL, no_NO, pt_BR, pt_PT, ru_RU and sv_SE. This is a limitation of
60 ukeyboard and may be relaxed in the future. If you put one of these codes
61 into the "lang" clause, ukeyboard will give you a warning.
63 In general, the name in the "lang" clause should be a valid language code.
64 Ukeyboard permits the country code part to be anything (e.g. you can specify
65 en_DV for a Dvorak layout). To be safe, it's better to specify exactly two
66 letters in the country code part, though.
68 5. Different types of keyboards and layouts
69 -------------------------------------------
71 There are three types of .vkb files. The first one is an on-screen keyboard
72 corresponding to a selected language, the second one is a special keyboard
73 activated by pressing the "&!e" button, the third one is a "scv" keyboard,
74 which is displayed by pressing the "Chr" key on the sliding keyboard.
75 Although vkb_compiler is able to compile all of them, this document covers
76 the first type only. By a "keyboard" or "keyboard layout" the first type of
77 the keyboard is meant through the whole document. For a "scv" type, read
78 this document and then look at the examples in keyboards-scv/ directory.
80 Each keyboard file contains two keyboard layouts - one for a normal (stylus)
81 and one for a thumb keyboard.
83 A normal layout has two parts, alpha and numeric keyboard, in two variants,
84 lowercase and uppercase. This gives four "sublayouts" for a normal layout.
86 A thumb layout has two mandatory "sublayouts", lowercase and uppercase alpha
87 keyboard, and an arbitrary number of "special" sublayouts. They are
90 Remember, both layouts (normal+thumb) have to be defined.
92 6. Description of the .def file format
93 --------------------------------------
98 Every keyword, symbol, etc. has to be separated by a whitespace (a space,
99 a tab or a newline). Especially, be aware that a whitespace is required
100 before and after { and }.
102 A # character starts a comment; everything following the # character is
103 ignored until the end of line. This has one exception, though. If
104 a character in a key definition is expected, # is considered a valid
105 character and doesn't have a special meaning.
111 A .def file has to start with a header section:
113 ...header definition...
116 Inside the header, few global things are defined:
117 - a descriptive name of the keyboard
119 - default word completion dictionary
122 6.2.1 Descriptive name of the keyboard
123 --------------------------------------
125 A descriptive name of the keyboard is defined by:
126 name "descriptive name"
128 Ukeyboard uses this name in the list of kayboards in Text input settings
129 applet. The OS itself seems to just ignore the name, though.
134 The locale name of the keyboard. See section 4.2 for allowed values of this
135 field and section 4.1 for a discussion about allowed .vkb file names.
140 6.2.3 Word completion dictionary
141 --------------------------------
143 When selecting the keyboard layout in the Control panel, a corresponding
144 word completion dictionary is preselected. This is specified by this clause.
152 Each key in the keyboard has its dimensions. These dimensions are not
153 specified in the key definition, though. Instead, each key has a single
154 "size number" assigned. The actual dimensions for the "size number" are
155 specified in the header.
157 The header can contain an arbitrary number of key sizes. The key size
158 definition looks like this:
159 size 0 { width 35 height 35 textpos 26 left 0 top 0 }
161 The number after the "size" keyword (0 in the example) specifies the size
162 number. You'll use this number in key definitions to specify the size of the
165 "width" and "height" specify the dimensions of the key in pixels. (Note that
166 if the sum of widths of keys in a row is more or less than the expected
167 width, it is proportionally enlarged/shrinked. The same applies to heights.)
169 "texpos" denotes vertical position of the text on the key (the baseline).
171 "left" and "top" specify left and top padding of the key (i.e. the empty
172 space between the previous and this key).
174 6.3 Layouts and sublayouts
175 --------------------------
177 After the header, layout sections are present. They are defined as:
179 ...normal keyboard layout definition...
183 ...thumb keyboard layout definition...
186 Inside kbd_normal, the following sections are defined:
189 ...alpha lowercase keyboard...
192 ...numeric lowercase keyboard...
195 ...alpha uppercase keyboard...
198 ...numeric uppercase keyboard...
202 Inside kbd_thumb section, the following sections are defined:
205 ...alpha lowercase keyboard...
208 ...alpha uppercase keyboard...
211 ...keyboard on the second tab...
214 ...keyboard on the third tab...
219 Definitions in the sublayout sections are the same for normal and thumb
220 keyboard, except the "name" clause, which can be present only in the thumb
223 6.4 Sublayout definition
224 ------------------------
226 A sublayout definition contains the following clauses (the numbers and
227 values are just examples):
239 6.4.1 Name of the sublayout
240 ---------------------------
242 The "name" clause can (and must) be present in thumb keyboard sublayouts
243 only. It specifies the name displayed on the corresponding tab.
248 Folowing the "margin" clause, four numbers are specified. They denotes
249 margins of the keyboard starting from top and going clock-wise (i.e. top,
250 right, bottom, left).
252 The margins are used for separating of the numerical from alpha keyboard.
257 The "default_size" clause specifies the default size number for keys in this
258 sublayout. By specifying this, you don't need to add the "size" attribute to
261 Remember, the value refers to the dimensions specified in the header.
263 6.4.4 Row definitions
264 ---------------------
266 An arbitrary number of rows of keys can be present in each sublayout. See
272 Each key row consists of several keys. The number of keys can be different
275 The row definition looks like this:
283 There are several ways to define a key, depending on a type of the key:
286 slide { key X key X key X }
288 Independently on the type, each key can have attributes. The attributes are
289 given after the key definition, e.g.:
292 The order of the attributes is not important. The recognized attributes are:
304 There are three key types:
307 3. slide keys (repeated pressing of the slide key cycles through a set of
313 After the "key" keyword, the whitespace is required, followed by a single,
314 UTF-8 encoded, character (*). This character will be displayed on the key
315 and printed when the key is pressed by user.
317 After the "slide" keyword, a new section ({...}) has to be started,
318 containing a "key" keyword followed by a character, followed by a "key"
319 keyword, etc. A slide key can contain an arbitrary number of keys.
321 After the "white" keyword, there is (of course) no character specified.
323 (*) That's not exactly true. You can specify a bunch of characters, as long
324 as they don't contain a whitespace. It should work as expected, i.e.
325 outputting all the characters when the key is pressed. The author hasn't
331 The "alpha" attribute denotes an alpha key (i.e. letters A to Z plus
332 equivalents in other languages, including characters with a diacritic).
334 The "num" attribute denotes a numeric key (i.e. 0 to 9 and the minus sign).
336 The "hexa" attribute denotes a key that can be used in a hexadecimal input
337 (i.e. 0 to 9 and A to Z).
339 The "tele" attribute denotes a key present on a telephone keypad (i.e.
340 0 to 9, *, #, and few other keys).
342 The "special" attribute denotes a non-alphanumeric key (i.e. key that is
343 neither a letter nor a number).
345 The "dead" attribute denotes the key is a combining diacritical mark
346 (a so-called "dead key").
348 The "size" attribute is used when the size of the key should be different
349 than the default size for this sublayout. Again, remember that the value
350 refers to the dimensions specified in the header.
352 7 Contact, legal stuff
353 ----------------------
355 The document is (c) Jiri Benc, <jbenc@upir.cz>. It is licensed under the
358 If you find an error in this document, please contact the author.
360 maemo is an unregistered trademark of Nokia Corporation.