Openmoko keyboard mockup

Carsten Haitzler (The Rasterman) raster at
Tue Jan 6 11:17:14 CET 2009

On Tue, 6 Jan 2009 10:14:19 +0100 kimaidou <kimaidou at> babbled:

> Ok. Thanks both for your usefull answers.
> @Vasily : T9 is patented, but we can reproduce the same functionnality, as
> OpenOffice did with Microsoft Office, or am I missing something ?

no you can't a patent coverts any form of reproduction of the idea. its not
copyright. the way the illume kbd works as best i know bypasses apples patent
on the iphone kbd (which enlarges hit areas for keys based on the most likely
key you want next also based on dictionary lookup) as it works differently (not
playing with hit areas at all but using distances to keys). it doesnt do
anything like t9 that could be violating the patent - so as such unless you come
up with a better way to enter stuff that isnt patented... good luck! my take on
the Fr touchscreen:

1. avoid drags - you have to press hard with a finger to retain enough
pressure to keep a press down. it's a resistive screen meant for a stylus - a
sharp point. a finger is not a small sharp point thus more pressure is needed
to keep things down soa press is registered and stays registered.
2. stick to taps - it's easy to tap a finger down with a bit of speed to thus
get enough momentum and press the screen to get a tap - but maintaining as
above is much harder and should be avoided. so input methods that need a press
+drag (a lot) are going to be painful with fingers - avoid them like the
plague. they are nice theories - and work with styluses. good luck doing it
with a finger.

so.. now you want an input method that uses taps. you want something that is
familiar/easily learnable by people. you can do dasher. you can do all sorts of
out-there input methods people dream up. humans are creatures of habit. we like
the familiar. so... you could go the "qwerty - familiar if you ever used a
computer or typewriter" or "abc def ghi ..." arrangement (in fact the illume
kbd can do this just fine - go make a .kbd file with keys laid out like they
are on a numberpad! it will work - just fine! thats the idea of .kbd layout
files - it puts the power in the hands of (advanced) users without having to
code to be able to do new keyboard layouts). the core dictionary and fuzzy
matching code is the same and applies to both. some people will find the qwerty
layout more familiar - some the abc def ghi etc. numberpad layout better... all
the mechanisms, file formats and power is there - just waiting to be
harnessed. :) (i love writing stuff to be generic to tackle a problem in a
broad way to solve lots of problems in one foul swoop - it is a painful entry
barrier to get it done to begin with, but once done and tuned - is nice how its
so flexible with just some config swizzling - it solves a problem a whole new
way etc.) :)

> @Xavier : Ah ah, I completely lost this one ! I wil try it now
> @ both and others : what about transparency ?

see my long long long email about the kbd. :)

> 2009/1/6 Xavier Cremaschi <omega.xavier at>
> > > I don't get how the dictionnary (illume and qtopia) actually helps to
> > > write some word.
> >
> > To write "forest" with illume keyboard you just have to type :
> > - near the f key
> > - near the o key
> > - near the r key
> > - near the e key
> > - near the s key
> > - near the t key
> > For each key you type, the illume keyboard makes the hypothesis that you
> >  probably type near the right key but not exactly on the right key, so
> > with these 6 different positions (for "forest") it searches in its
> > dictionary all the possible words.
> >
> > That's why "for" and "die" come together.
> >
> >
> > Xavier.
> >
> >
> > _______________________________________________
> > Openmoko community mailing list
> > community at
> >
> >

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at

More information about the community mailing list