[Trac #418] Keyboard layout collector ticket.

[Zarro Boogs per Child]

#418: Keyboard layout collector ticket.
-----------------------+----------------------------------------------------
 Reporter:  jg         |        Owner:  J5     
     Type:  defect     |       Status:  new    
 Priority:  blocker    |    Milestone:  BTest-2
Component:  keyboards  |   Resolution:         
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by walter):

 I had posted the corrections to the keyboard mappings in Ticket #443. I
 will post them at their individual tickets (most of which had been closed)
 and create a new ticket for Urdu. The other issue is making sure that we
 properly configure the xorg.conf file for each language. We have a bi of
 inconsistency in terms of how we are handling things: most keyboards are
 olpc variants of standard X symbol files. Nigeria is a new keyboard and
 hence is not a variant--perhaps something I should fix for B3... Also, I
 think that for the time being, we should have X default to a Latin
 keyboard at start up, so Thai, Arabic, and Urdu should all have multiple
 group entries.

 So:

 US International:

 {{{
 Option "XkbLayout" "us"
 Option "XkbVariant" "olpc"
 }}}

 Brazil (Portuguese):

 {{{
 Option "XkbLayout" "br"
 Option "XkbVariant" "olpc"
 }}}

 Spanish (Argentina):

 {{{
 Option "XkbLayout" "es"
 Option "XkbVariant" "olpc"
 }}}

 Nigeria:

 {{{
 Option "XkbLayout" "ng"
 }}}

 Thai:

 {{{
 Option "XkbLayout" "us,th"
 Option "XkbVariant" "olpc,olpc"
 }}}

 Arabic:

 {{{
 Option "XkbLayout" "us,ara"
 Option "XkbVariant" "olpc,olpc"
 }}}

 Urdu:

 {{{
 Option "XkbLayout" "us,ur"
 Option "XkbVariant" "olpc,olpc"
 }}}


 I have been generating the keyboard layouts using an SVG file. I cannot
 quite do it automatically--it needs a bit of hand-tweaking each time. That
 said, it is relatively easy to create from an Xkb Symbol file. I suggest
 we just stick to using them until we encounter a scaling problem. At some
 point we need to look at using SCIM instead/in addition to Xkb.

 Another decision we need to make (in part resolved by going to SCIM) is
 the encoding: I have been favoring Unicode to the X definitions, as it is
 more complete. But this has an implication in terms of how compose/dead
 characters work: Unicode uses composite characters, which implies you type
 the accent, then the character. X uses dead characters, which implies you
 time the character, then the accent. We have a bit of an inconsistency
 right now--a mix of both. Again, SCIM can help us here.

 -walter

-- 
Ticket URL: <http://dev.laptop.org/ticket/418#comment:12>
One Laptop Per Child <http://laptop.org/>