dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Search | Go
Wiki > Main > TWikiUsers > JoelPuik > VKeyboardDesignProposal

Cross target onscreen keyboard design proposal


note: To make things clear: I am in now way a programmer and you will find no real code from my hand, only pseudo code.
Anyway, if anyone who can program has anything to add to this document, I invite them to do so. JoelPuik



The goal of this document is to design a cross target onscreen keyboard as a replacement for the current default.
The design is based on the following principals:
  • Easy to update target independent character layout.
  • Multiple page/screen support per character set, where the pages can be chosen in a menu-like fashion.
  • Per target optimised appearance.
  • Easy to implement into plugins and other programs, including a definable textarea for optimum intergration.

This document is to be treated as a functional design and as a result will mainly contain concepts, which need to be further developed when a general consensus on the functionality and layout of the keyboard is reached.

Note: Not all targets are illustrated in this document. However, the same concepts can be applied to the other targets as well. Some sections in this document may be either incomplete or over complete.

Note on charcell targets. The character sets are to be diplayed in a single row in alphabetic order. To accomodate as much characters as possible the characters can be divided amongst multiple pages. (JoelPuik)

1. General screen layout.

The screen consists of two main areas as follows:
  • input
  • keyboard

To toggle the navigation between these two fields the user holds the selection button.


1.1 Input area

The input area holds the text which is generated with the keyboard. It consists of at least one line of text.

1.3 Keyboard area

The keyboard consists of two parts:
  • menu
  • character list


The menu holds options to change between character sets and character subsets.
Examples are a shift key to make the next character an uppercase character; Caps lock to make all following characters uppercase; Symbols to show a symbol character subset and accents which shows accented characters, like .

The character list shows a list of characters. Which characters are shown depends on the chosen language and character (sub)set. The different sets are to be defined later in the design process.

2. Detailed screen layout

Note: Since the input area only shows lines of typed text it will be not discussed in great detail in this section. (JoelPuik)

2.1 input area

The input area holds the text typed with the keyboard. The text will be displayed as left aligned text starting on the top line.

2.2 keyboard area

The items in the menu area are displayed as a list, from top to bottom. When a menu item is selected the functionality should change temporally to enable the user to return to the default layout.

Note: added functionality if there are more items than would fit in the standard menu area the remaining options could be displayed by using a vertical scrollbar. This scrollbar should be placed on the left side of the menu area
To leave the menu area the user navigates to the keyboard by pressing the button to go to the left. This also should reset the menu to the default state. (JoelPuik)


The character area can be divided into 4 rows and ~16 columns

3. Character sets

This section defines the character sets which will be displayed in the character area.
Any blank spot functinos as a space. Character deletion has yet to be defined.

How many of the charactersets below are to be implemented is subject to change, depending on how many users want a particular layout.

Note: If a character set consists of characters which may be constructed out of two other characters (glides, etc.) the rules for this need to be explained in further detail. (JoelPuik)

3.1 Latin

This character set has 4 menu options:
  1. shift The first following character will be in uppercase
  2. caps Until this option is chosen again, all following characters will be in uppercase.
  3. acc Accented characters
  4. sym Symbols

Since most users rarely use multiple symbols in succession, the character list should jump back to default state when a character has been entered while in the symbol character set.

a b c d e f g h i     1 2 3    
j k l m n o p q r     5 6 7    
s t u v w x y z       7 8 9    
. , ? !         _     0      

Default + Caps
A B C D E F G H I     1 2 3    
J K L M N O P Q R     4 5 6    
S T U V W X Y Z       7 8 9    
. , ? !         _     0      

Acc (accents)
. , ? !         _            

Acc + Caps
. , ? !         _            

! " # $ % & ' ( ) * + , - . / :
; < = > ? @ [ \ ] ˆ _ ` { | } ~
- ¯

3.2 Greek

needs verification

This character set has 3 menu options:
  1. shift The first following character will be in uppercase
  2. caps Until this option is chosen again, all following characters will be in uppercase.
  3. sym Symbols

α β γ δ ε ζ η θ ι     1 2 3    
κ λ μ ν ξ ο π ρ σ     4 6 5    
τ υ φ χ ψ ω     ς     7 8 9    
, . ? !                 0      

Α Β Γ Δ Ε Ζ Η Θ Ι     1 2 3    
Κ Λ Μ Ν Ξ Ο Π Ρ Σ     4 6 5    
Τ Υ Φ Χ Ψ Ω           7 8 9    
, . ? !                 0      

! " # $ % & ' ( ) * + , - . / :
; < = > ? @ [ \ ] ˆ _ ` { | } ~
- ¯

3.3 Cyrillic

3.3.1 Russian (verified)

This character set has 3 menu options:
  1. shift The first following character will be in uppercase
  2. caps Until this option is chosen again, all following characters will be in uppercase.
  3. sym Symbols:

а б в г д е ё ж з     1 2 3    
и й к л м н о п р     4 5 6    
с т у ф х ц ч ш щ     7 8 9    
ь ы ъ э ю я , . ? !     0      

А Б В Г Д Е Ё Ж З     1 2 3    
И Й К Л М Н О П Р     4 5 6    
С Т У Ф Х Ц Ч Ш Щ     7 8 9    
Ь Ы Ъ Э Ю Я , . ? !     0      

! " # $ % & ' ( ) * + , - . / :
; < = > ? @ [ \ ] ˆ _ ` { | } ~
- ¯

3.3.2 Macedonian

This character set has 3 menu options:
  1. shift The first following character will be in uppercase
  2. caps Until this option is chosen again, all following characters will be in uppercase.
  3. sym Symbols:

а б в г д ѓ е ж з     1 2 3    
ѕ и ј к л љ м н њ     4 5 6    
о п р с г ќ у ф х     7 8 9    
ц ч џ ш , . ? !         0      

А Б В Г Д Ѓ Е Ж З     1 2 3    
Ѕ И Ј К Л Љ М Н Њ     4 5 6    
О П Р С Т Ќ У Ф Х     7 8 9    
Ц Ч Џ Ш , . ? !         0      

! " # $ % & ' ( ) * + , - . / :
; < = > ? @ [ \ ] ˆ _ ` { | } ~
- ¯

3.4 Hebrew

This character set has 2 menu options:
  1. Default
  2. Symbols

    7 8 9       ח ז ו ה ד ג ב א
    4 5 6       נ ם מ ל ך כ י ט
    1 2 3       ק ץ צ ף פ ע ס ן
      0         ? ! : . , ת ש ר

! " # $ % & ' ( ) * + , - . / :
; < = > ? @ [ \ ] ˆ _ ` { | } ~
- ¯

3.5 Japanese

This character set has 3 menu options:
  1. Hiragana (Consisting of 46 characters + 10 small characters)
  2. Katakana (Again with 46 characters + 10 small characters)
  3. Symbols


Hiragana + shift:



! " # $ % & ' ( ) * + , - . / :
; < = > ? @ [ \ ] ˆ _ ` { | } ~
- ¯

Kanji characters would be pointless to implement on such an input as there are literally thousands of different characters. We should also discuss whether or not to break up the individual alphabets into multiple pages to reflect how the kana are usually laid out (eg.

There are two layouts. The image shows a left-to-right top-to-bottom. There is another layout, also widely used, which is top-to-bottom right-to-left. Using the Japanese keyboard layout is probably the easiest.

The small characters can be achieved with a "shift" key that generates the small characters. Perhaps the shift key should repaint the keyboard with only the small keys?

What about voiced and semi-voiced marks? I think I would prefer to have all characters precomposed in the palette too. -- MikaelMagnusson - 28 Mar 2006
If that makes the keyboard more complete, feel free to define an alternate layout.(max 16x4 grid) Since I myself have insufficient knowledge about the matter. JoelPuik

3.6 Korean (Hangeul)

needs verification

This character set has 1 menu option:
  1. default


The words are created in the same way as with

3.7 Thai

needs verification

This character set has 2 menu options:
  1. default
  2. shift

kedmanee layout:


default + shift

Appendix A: Technical design

This section contains some thoughts on the actual implementation.

A.1 flowchart


A.2 implementation method of the keyboard in plugins and other programs.

This section describes how a developer can implement the keyboard in a plugin or other program.

The keyboard should be able to be implemented by inserting only a few lines of code to define the keyboard itself, define the input area and optionally the background image/color and text color.

Possible example (pseudo code):
insert keyboard(customInputarea); (which should load the keyboard and write the text generated by the keyboard to the chosen variable/target area.)

Possible example with optional colors(pseudo code):
inputarea = customarea;
keyboardcolor = [bgchar,bgmenu , txtchar, txtmenu] ; (in reality this would be something like: [#FFFFFF, #888888, #000000, #000000] )
insert keyboard(inputarea, keyboardcolor);

If no custom input area is chosen the part of the screen which is not covered by the keyboard becomes the input area.

A.3 how to handle future layouts

First off: the character layout should be seperate from target specific code.
That way, when new targets are supported by rockbox, only a graphic definition has to be written. (this contains fontsize and colors amongst others)

It should be made easy to implement future layouts.
This could be done by using some kind of layout file, where all layouts and their menu options are defined. (One could think about an XML like structure) This file can be either hardcoded (only to be edited prior to compiling) or as a script-like or configuration file.

A.4 shift and caps behaviour

Shift and Caps and menu options should just select the next page in line on selection and to the previously selected page upon deselection.

The main difference in behaviour between the two lies in the fact that the shift option returns to the previous page on character selection, while the caps option does this only when the user deselects the caps set.

Other pages that are defined as one-character inputs should return to the default character page upon character selection. (ie. page 0)

A.5 possible character set handling

possible method 1: arrays

For this you need three types of arrays or less if you use multi-dimensional arrays.
  • an array that contains an overview of the layouts
  • an array that contains the menu options per layout (multi-dimensional?)
  • an array that contains the pages per layout (multi-dimensional)
layout overview: array1=['latin','russian','greek'];
menu options: array2=['default','caps','acc','symbols']['default','caps','symbols']['default','caps','symbols'];
layout pages: array3=['','ABC...XYZ', etc]['абв...эюя','АБВ...эюя','etc.']['...','...']

possible behaviour (pseudocode, probably full of errors ):
(order: choose layout, choose menu option)

//show available layouts, generally this is only done when the user calls for it
while array1 {
   display array1[n1]
on menuoption n=n1
//show menu options
while array2[n] {
   display array2[n][n2]  //I have no idea how you handle multi-dimensional arrays

//show characters
on menuoption:  n=n2 (ie. 1)
display array3[n][n3]
  1. show all available layouts
  2. Show the chosen layout. (all menuoptions and default page)
    • show all menu options
    • show the default page (the first one in the array, or array3[n][0])

possible method 2: structured file

  • layout
    • menuoptions
      • page
  • layout
    • menuoptions
      • page

This should work the same as xml

Appendix B: Graphic design

This section is to describe the actual appearance of the keyboard.

B1. appearance

On color targets the keyboard should have a simple color scheme, consisting of a maximum of four colors:
(with suggested colors between () ).
  1. menu background (grey)
  2. menu text (black)
  3. characterlist background (white)
  4. characterlist foreground (black)

On greyscale targets the colorscheme should be similar, with the exception that the colors are obviously limited to greyscale values.

On b/w targets the division between the menu and characterlist is defined by a border.

On all targets the keyboard should have a 1px border at the top.


Appendix C: Suggestions and discussion

This section is meant for additional suggestions and to discuss certain design choices.

MarcoenHirschberg: A patch for vkeyboard with support for loadable unicode layouts:

JeongTaekIn suggested you should be able to change the character sets on the fly.
note: possibly with a menu of some sort. (ie. a menu that lists all available character sets)
r33 - 26 Apr 2006 - 06:39:53 - JoelPuik

Parents: TWikiUsers > JoelPuik
Copyright by the contributing authors.