|
|
Wiki > Main > VKeyboardDesignProposal (compare)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Difference: VKeyboardDesignProposal (r32 vs. r31)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. ContentsIntroduction The goal of this document is to design a cross target onscreen keyboard as a replacement for the current default.
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:
To toggle the navigation between these two fields the user holds the selection button.
1.1 Input areaThe input area holds the text which is generated with the keyboard. It consists of at least one line of text. 1.3 Keyboard areaThe keyboard consists of two parts:
The menu holds options to change between character sets and character subsets. 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 layoutNote: 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 areaThe 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 areaThe 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
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. 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 LatinThis character set has 4 menu options:
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. Default
Default + Caps
Acc (accents)
Acc + Caps
Symbols
3.2 Greekneeds verificationThis character set has 3 menu options:
default:
default+caps
symbols
3.3 Cyrillic3.3.1 Russian (verified)This character set has 3 menu options:
default
default+caps
symbols
3.3.2 MacedonianThis character set has 3 menu options:
default
default+caps
symbols
3.4 Hebrew This character set has 2 menu options:
Default
Symbols
3.5 JapaneseThis character set has 3 menu options:
Hiragana:
Hiragana + shift:
Katakana:
Katakana+shift:
Symbols:
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. http://www.komi.com/japanese/hir/hiragana.gif ). 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 3.6 Korean (Hangeul)needs verificationThis character set has 1 menu option:
Default
The words are created in the same way as with http://www.rockbox.org/tracker/task/4856 3.7 Thaineeds verificationThis character set has 2 menu options:
note:There seem to be two thai keyboard layouts. I don't know which is the most common. pattachote layout: default
default + shift
kedmanee layout: default
default + shift
Appendix A: Technical designThis 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): Possible example with optional colors(pseudo code): 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. It should be made easy to implement future layouts. A.4 shift and caps behaviourShift 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 handlingpossible method 1: arraysFor this you need three types of arrays or less if you use multi-dimensional arrays.
example: possible behaviour (pseudocode, probably full of errors ):
n1,n2,n3=0
//show available layouts, generally this is only done when the user calls for it
while array1 {
display array1[n1]
++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
++n2
}
//show characters
on menuoption: n=n2 (ie. 1)
display array3[n][n3]
rundown:
possible method 2: structured file
This should work the same as xml Appendix B: Graphic designThis 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:
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 discussionThis section is meant for additional suggestions and to discuss certain design choices. MarcoenHirschberg: A patch for vkeyboard with support for loadable unicode layouts: http://www.rockbox.org/tracker/task/4856 JeongTaekIn suggested you should be able to change the character sets on the fly. r33 - 26 Apr 2006 - 06:39:53 - JoelPuik
Revision r32 - 31 Mar 2006 - 17:14 - JoelPuikRevision r31 - 31 Mar 2006 - 15:40 - JoelPuik Copyright © by the contributing authors.
|