Re: Openmoko keyboard mockup

[Pander]

Levy A. M. Sant'Anna wrote:
> Did someone created another keyboard for terminal layout?
> I did, but is not so good, yet.
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

http://wiki.openmoko.org/wiki/Illume#List_of_illume_keyboards

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Levy A. M. Sant'Anna]

Did someone created another keyboard for terminal layout?
I did, but is not so good, yet.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Software Patents [was Re: Openmoko keyboard mockup]

[Arthur Marsh]

kimaidou wrote, on 2009-01-15 18:53:
> Hi all
> No offense, but could you please rename the topic with "patents something"
> instead of keyboard mockup ? I let you choose the right one though.
> thanks in advance.
> 
> 2009/1/15 Arthur Marsh 
...

>> But the software patent is undecipherable gobbledegook rather than
>> GPL-mandated copy of source code in its usual form for editing and
>> development including sensible variable names, comments, makefiles,
>> build scripts and everything that is not already available in other GPL
>> packages to make it run.
>>
>> Arthur (trying to give the black knight of software patents another
>> flesh wound).

My apologies, a few months after reading all the discussion involving a 
Mr Quinn on groklaw.net I let go and put into a few words some of what 
is broken about software patents on this mailing list.

I am hoping that published, some-flavour-of-GPL licensed software (and 
hardware), such developed by the openmoko project will lead to more 
people improving software and fewer people being involved in being 
software (and hardware) patent trolls.

Arthur (coconut shells clip-clopping into the distance).


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

Hi all
No offense, but could you please rename the topic with "patents something"
instead of keyboard mockup ? I let you choose the right one though.
thanks in advance.

2009/1/15 Arthur Marsh 

> Chris Samuel wrote, on 2009-01-13 18:42:
> > On Fri, 9 Jan 2009 5:11:45 am Stefan Monnier wrote:
> >
> >>> [1] - which is ironic given that they were invented to encourage people
> >>> to publish their ideas rather than keep them secret.
> >> Actually, not so ironic: it basically means that rather than keeping
> >> them as internal secrets, they get to lock them in
> >> a government-provided vault.
> >
> > Where everyone can read them and the protection expires after a time.
> >
> > Don't get me wrong, I think patents are bad, especially these days where
> the
> > techniques are often obsolete before the patent expires. :-(
>
> But the software patent is undecipherable gobbledegook rather than
> GPL-mandated copy of source code in its usual form for editing and
> development including sensible variable names, comments, makefiles,
> build scripts and everything that is not already available in other GPL
> packages to make it run.
>
> Arthur (trying to give the black knight of software patents another
> flesh wound).
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Arthur Marsh]

Chris Samuel wrote, on 2009-01-13 18:42:
> On Fri, 9 Jan 2009 5:11:45 am Stefan Monnier wrote:
> 
>>> [1] - which is ironic given that they were invented to encourage people
>>> to publish their ideas rather than keep them secret.
>> Actually, not so ironic: it basically means that rather than keeping
>> them as internal secrets, they get to lock them in
>> a government-provided vault.
> 
> Where everyone can read them and the protection expires after a time.
> 
> Don't get me wrong, I think patents are bad, especially these days where the 
> techniques are often obsolete before the patent expires. :-(

But the software patent is undecipherable gobbledegook rather than 
GPL-mandated copy of source code in its usual form for editing and 
development including sensible variable names, comments, makefiles, 
build scripts and everything that is not already available in other GPL 
packages to make it run.

Arthur (trying to give the black knight of software patents another 
flesh wound).


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Chris Samuel]

On Fri, 9 Jan 2009 5:11:45 am Stefan Monnier wrote:

> > [1] - which is ironic given that they were invented to encourage people
> > to publish their ideas rather than keep them secret.
>
> Actually, not so ironic: it basically means that rather than keeping
> them as internal secrets, they get to lock them in
> a government-provided vault.

Where everyone can read them and the protection expires after a time.

Don't get me wrong, I think patents are bad, especially these days where the 
techniques are often obsolete before the patent expires. :-(

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP



signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[leona...@lilik.it]

Stefan Monnier wrote:
>> [1] - which is ironic given that they were invented to encourage people to 
>> publish their ideas rather than keep them secret.
> 
> Actually, not so ironic: it basically means that rather than keeping
> them as internal secrets, they get to lock them in
> a government-provided vault.
> 
> IIRC, the history of patents is a bit more interesing than people think,
> and the end result's paradoxes are not as unintended as you'd think.
> But it really should be expected: just as is still the case now (if not
> even more), the (potential) holders of big patent portfolio had a lot
> of leverage.

We're going quite OT, but it's a nice talk.

I thought I posted this link to the list, but instead I replied directly
to Raster. On this topic I found quite interesting this book:
http://levine.sscnet.ucla.edu/general/intellectual/against.htm

Basically, there seems to be no evidence anywhere that patents ever
helped development, in any age and country where applied. Obviously, the
owner of T9 patent are richer then they were in 1995, but in general
they produce more expenses then profits.

leonardo.

-- 
http://leonardo.lilik.it
Key fingerprint = 2C20 A587 05AC 42E5 1292  D0D4 3EED CFB5 52FD AD1E

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[leona...@lilik.it]

Helge Hafting wrote:
> leonardo wrote:
> 
> More important, the patent is about "reduced keyboard disambiguating".
> If the keyboard isn't "reduced", i.e. it has all the keys, then
> that patent doesn't seem to apply.
> 
> The illume keyboard aren't missing any keys for example. It only uses a 
> dictionary because users sometimes miss. There is no ambiguity at all to 
> resolve, only error correction for fat-fingered typing. (T9 does not
> try to resolve wrong-key misses) Disambiguating and error correction
> is not the same.
> 
> Oh, and they mention "keyboards". Many phones has keyboards with about
> 12 keys.  The neo has a touchscreen instead, its two keys are not used
> for text input. :-)

you're right.. what I meant while writing is that, since moko keyboard
is not reduced, it could even suggest words instead of only correct
errors without infringing T9.

leonardo.

-- 
http://leonardo.lilik.it
Key fingerprint = 2C20 A587 05AC 42E5 1292  D0D4 3EED CFB5 52FD AD1E

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Stefan Monnier]

> [1] - which is ironic given that they were invented to encourage people to 
> publish their ideas rather than keep them secret.

Actually, not so ironic: it basically means that rather than keeping
them as internal secrets, they get to lock them in
a government-provided vault.

IIRC, the history of patents is a bit more interesing than people think,
and the end result's paradoxes are not as unintended as you'd think.
But it really should be expected: just as is still the case now (if not
even more), the (potential) holders of big patent portfolio had a lot
of leverage.


Stefan


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Helge Hafting]

leonardo wrote:
> Rui Miguel Silva Seabra ha scritto:
> 
>>> it's cool, you should really patent it!
>>> :-)))
>> Please die a slow and painful death for suggesting that. [1]
>>
>> Rui
>>
>> [1] unless you were really just making a very bad taste joke :)
> 
> Of course it was [1]...
> T9 is quite emblematic for software patents and patents in general:
> someone patents something which is really nothing revolutionary, the
> effort to produce such an invention is really low, but nobody can
> come-up with something similar for the fear of being sued.
> If you look at the patent itself (wikipedia says:
> http://www.google.com/patents?id=PmgCEBAJ) you see it's 27 pages of
> pointless diagrams and 7 pages of a very vague description of how a
> "reduced keyboard disambiguating computer".
> At a very fast lecture, the patent might not even apply to our case,
> since it says:
> "The keyboard has twelve keys, nine of them labeled with numerous
> letters and other symbols, and those nine plus one more are labeled each
> with one of the ten digits". It seems if your keyboard doesn't have 12
> keys you're safe. I wouldn't be surprised if T2-T26 would be patented too..

More important, the patent is about "reduced keyboard disambiguating".
If the keyboard isn't "reduced", i.e. it has all the keys, then
that patent doesn't seem to apply.

The illume keyboard aren't missing any keys for example. It only uses a 
dictionary because users sometimes miss. There is no ambiguity at all to 
resolve, only error correction for fat-fingered typing. (T9 does not
try to resolve wrong-key misses) Disambiguating and error correction
is not the same.

Oh, and they mention "keyboards". Many phones has keyboards with about
12 keys.  The neo has a touchscreen instead, its two keys are not used
for text input. :-)

Helge Hafting

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Chris Samuel]

On Thu, 8 Jan 2009 2:35:13 am leonardo wrote:

> If you look at the patent itself (wikipedia says:
> http://www.google.com/patents?id=PmgCEBAJ) you see it's 27 pages of
> pointless diagrams and 7 pages of a very vague description of how a
> "reduced keyboard disambiguating computer".

Of course if you do look at a patent and are later found to infringe it you 
may be liable to pay triple damages for willful infringement if you ended up 
in a US court over it (and yes, I do realise you're in Italy :-) ).  :-(

http://www.internetnews.com/bus-news/article.php/3500546

# Under current patent law and its interpretation by the courts, punitive
# triple damages are imposed if the party infringed willfully. Simon said mere
# knowledge that the infringed patent exists can support a finding of
# "willfulness," and liability for triple damages.

Moral of the story - never ever read patents, or anything about them! [1]

IANAL, batteries not included, etc..

cheers,
Chris

[1] - which is ironic given that they were invented to encourage people to 
publish their ideas rather than keep them secret.

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP



signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Thu, 8 Jan 2009 02:31:34 +1100 Ian  babbled:

> > i'd rather not. 1. trollt.. err.. nokia deserve thanks for the core
> > inspiration and initial work on their one - i didn't know how the code
> > worked until later but i nutted out how it probably should work just by
> > poking at it. so if anyone deserves a patent - it's them. 2. i'd rather
> > this be well publicised and "out there" code in the public eye - so the
> > idea is widespread and well known - thus serves as prior art pretty much
> > making it impossible for someone to come along and patent the idea and make
> > things a pain. get the ideas out there in code - in the public eye with a
> > trail of history so it's available for everyone to see and use. if someone
> > implements a better kbd but steals the same idea - i'm sticking my thumbs
> > up going "good on-ya mate!" i want users and the community to benefit. 3. i
> > fundamentally disagree with software patents - or at least the way they
> > have been implemented. the vast majority i have seen are neither novel nor
> > "non-obvious to someone skilled in the art". most are incredibly mundane
> > straightforward things to "someone skilled in the art" and the system has
> > been abused to further greed and misplace credit in the hands of those with
> > more lawyers, not those who innovate the most or the best. be that as it
> > may - the system is there and we are stuck with it. i'm not a crusader
> > trying to bring it down - i don't have the time. got code to write and
> > ideas to make happen :) but i hope in my little way i can shake my fist at
> > the system and go "here... prior art. take that!". i'll let others fight
> > the good fight in trying to reform the patent system. i'm just rattling my
> > chains and moaning in my corner... 'brains! brains! braiins! need
> > moore brains!' :)
> 
> Raster... you are my new hero. It's not the first time I've heard this
> kind of argument (Andrew Tridgell made a very similar argument at a
> CLUG meeting some time ago) and I completely agree with you.
> 
> Good work on the keyboard,

tridge is an awesome bloke. smart smart smart man. i'd aspire to be as smart as
tridge one day when i grow up! :) (seriously - he is smart!)

now... where's my brains.. :)
tnx :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Ian]

>  Maybe it would be better to have a full-screen input mode where you
> can see what will be typed (maybe keep the rightmost 20-30 characters of
> the string visible in the keyboard app, then actually pass it to the
> program when leaving 'full-screen' mode or pressing 'enter', etc). That
> still allows you to see what you are typing with a full-screen keyboard
> (which is what it seems most people are wanting from the transparency).
>
>  Extra points could be awarded for allowing applications to give the
> keyboard app a description of the 'active' field to be displayed
> in a 'full-screen' mode.


Yeah, that reminds me a lot of the fullscreen keyboard on the Nokia N800:
http://arstechnica.com/reviews/hardware/n800.ars/4

The keyboard can be brought up by either:
- If enough pressure is applied to select a text field (significantly
more than the stylus can, but still only requires a firm push with a
finger/thumb), though this doesn't always work reliably
- Pressing the "rocker" key in the middle of the directional keypad
when the stylus keyboard is displayed
- Changing the settings can enable it to always come up, even when the
stylus is used (or disable it altogether).

Once displayed, some notable functions which may not be obvious from a
screen shot:
 - If it was activated for a text field which can be edited (ie, not
an X terminal), the text will be placed in the text field on the
keyboard
 - The text field in the keyboard supports highlighting, overwriting,
moving left/right and so forth
 - As a word is entered, the single most likely completion in it's
dictionary will be displayed in the text field in another colour - if
tapped on, it will enter that word.
 - the button on the upper left (an underlined down arrow) dismisses
the keyboard and passes it's input to the application
 - the return button will also dismiss the keyboard, but will
additionally send a return keystoke
 - The large back key is backspace
 - The odd looking button just left of the return key brings up a menu
allowing cut, copy, paste and changing dictionaries/languages if a
second language has been selected in the settings (which appears to
also have the option to use both dictionaries simultaneously, though I
have not tried that functionality).
 - On the letters page, the lower right button selects punctuation in
a similar manner to many phones (1 tap: full stop, 2 taps: comma, 3:
question mark, 4: exclamation mark, 5: hyphen and so on). As it is
tapped, the symbols displayed update to indicate the current symbol
selected (in black) as well as the next two symbols that would be
selected by continuing to tap (in grey). These same symbols may also
be found on the 1!+ (numbers and common* symbols) tab, though they are
each on separate buttons (so, faster to enter ... for example)
 - Selecting the letters tab while in the tab swaps between lower and upper case

*what is considered a common symbol is debatable - the asterisk is on
the third tab, while Euros and Pounds are on the common symbols tab -
since I'm in Australia my preference would be to swap that around.
Notably, there are also many symbols (including accented characters)
which can be used in the small keyboard, which are not available in
the fullscreen keyboard at all (as far as I am aware).

You can also see an earlier version of the non full screen keyboard
(which I do not believe would be suitable for something as small as
the freerunner, especially with no stylus holder) here:
http://arstechnica.com/reviews/hardware/n800.ars/2

I personally wouldn't mind something similar to this on the freerunner
- probably best used in landscape/fullscreen mode with raster's
keyboard for portrait/small mode - accelerometer fun comes to mind to
toggle the modes - only needs to be active (and draining power) when
the keyboard is displayed (and probably a setting to disable the
behaviour somewhere logical).

Cheers,
-Ian

-- 
http://darkstarshout.blogspot.com/
--
On the day *I* go to work for Microsoft, faint oinking sounds will be
heard from far overhead, the moon will not merely turn blue but
develop polkadots, and hell will freeze over so solid the brimstone
will go superconductive.
 -- Erik Raymond, 2005
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[leonardo]

Rui Miguel Silva Seabra ha scritto:

>> it's cool, you should really patent it!
>> :-)))
> 
> Please die a slow and painful death for suggesting that. [1]
> 
> Rui
> 
> [1] unless you were really just making a very bad taste joke :)

Of course it was [1]...
T9 is quite emblematic for software patents and patents in general:
someone patents something which is really nothing revolutionary, the
effort to produce such an invention is really low, but nobody can
come-up with something similar for the fear of being sued.
If you look at the patent itself (wikipedia says:
http://www.google.com/patents?id=PmgCEBAJ) you see it's 27 pages of
pointless diagrams and 7 pages of a very vague description of how a
"reduced keyboard disambiguating computer".
At a very fast lecture, the patent might not even apply to our case,
since it says:
"The keyboard has twelve keys, nine of them labeled with numerous
letters and other symbols, and those nine plus one more are labeled each
with one of the ten digits". It seems if your keyboard doesn't have 12
keys you're safe. I wouldn't be surprised if T2-T26 would be patented too..

leonardo.

[1] don't agree on the "very bad" part anyway.. :-)

-- 
http://leonardo.lilik.it
Key fingerprint = 2C20 A587 05AC 42E5 1292  D0D4 3EED CFB5 52FD AD1E

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Ian]

> i'd rather not. 1. trollt.. err.. nokia deserve thanks for the core 
> inspiration
> and initial work on their one - i didn't know how the code worked until later
> but i nutted out how it probably should work just by poking at it. so if 
> anyone
> deserves a patent - it's them. 2. i'd rather this be well publicised and "out
> there" code in the public eye - so the idea is widespread and well known - 
> thus
> serves as prior art pretty much making it impossible for someone to come along
> and patent the idea and make things a pain. get the ideas out there in code -
> in the public eye with a trail of history so it's available for everyone to 
> see
> and use. if someone implements a better kbd but steals the same idea - i'm
> sticking my thumbs up going "good on-ya mate!" i want users and the community
> to benefit. 3. i fundamentally disagree with software patents - or at least 
> the
> way they have been implemented. the vast majority i have seen are neither 
> novel
> nor "non-obvious to someone skilled in the art". most are incredibly mundane
> straightforward things to "someone skilled in the art" and the system has been
> abused to further greed and misplace credit in the hands of those with more
> lawyers, not those who innovate the most or the best. be that as it may - the
> system is there and we are stuck with it. i'm not a crusader trying to bring 
> it
> down - i don't have the time. got code to write and ideas to make happen :) 
> but
> i hope in my little way i can shake my fist at the system and go "here... 
> prior
> art. take that!". i'll let others fight the good fight in trying to reform the
> patent system. i'm just rattling my chains and moaning in my corner...
> 'brains! brains! braiins! need moore brains!' :)


Raster... you are my new hero. It's not the first time I've heard this
kind of argument (Andrew Tridgell made a very similar argument at a
CLUG meeting some time ago) and I completely agree with you.

Good work on the keyboard,
-Ian


-- 
http://darkstarshout.blogspot.com/
--
On the day *I* go to work for Microsoft, faint oinking sounds will be
heard from far overhead, the moon will not merely turn blue but
develop polkadots, and hell will freeze over so solid the brimstone
will go superconductive.
 -- Erik Raymond, 2005
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Wed, 7 Jan 2009 00:33:41 +0100 "Laszlo KREKACS"
 babbled:

> > this is be doable. keyboard application can receive message for client,
> > message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE
> > and message data is one of:
> 
> Is it also possible to change the dictionary on the fly too? (if I
> understand correctly, you are changing the layout ofthe keyboard)
> 
> 
> Thank you for the pointer, I will digg it more!

no - dict isnt changeable - not by app. as such i havent addressed this beyond
"kind of input" that doesnt specifically require a layout or dict to be used -
but hints on input. it's up to the keyboard to do what it thinks it best there.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Laszlo KREKACS]

> this is be doable. keyboard application can receive message for client,
> message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE
> and message data is one of:

Is it also possible to change the dictionary on the fly too? (if I
understand correctly, you are changing the layout ofthe keyboard)


Thank you for the pointer, I will digg it more!

Best regards,
 Laszlo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 13:28:44 -0600 "The Digital Pioneer"
 babbled:

> I also am somewhat surprised by the lack of an excellent code-friendly
> keyboard. I use QWO because it actually has the capability of syntactical
> symbols and is relatively finger-friendly. Still, sometimes you just can't
> beat good ol' fashioned QWERTY. I like the idea, though, of a keyboard that
> takes up the entire screen with just a little space at the top to see what
> you're typing, and once you've finished you can dump the whole mess into
> whatever textbox is focused. A lot more real-estate that way. It doesn't
> have to be transparent either.
> 
> I read most of the explanation of Illume's error-corrective keyboard, and it
> sounded so great, I went and tried it. However, when everything except
> "Hello" was listed when I typed "hdllo" and "hwllo" I gave up on it. :(
> Also, it DESPERATELY needs a reset button to start over on the word, if it's
> not in the list.

yeah - deleting 1 char at a time is nasty. and yes. it seems not to find hello
in the dic - i suspect a bug or 2 in dict matching and stopping a search too
early. again loop around back to "need a better dic format" :)


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 15:14:56 +0100 Mathieu Rochette  babbled:

> Laszlo KREKACS wrote:
> > Hi!
> >
> >>> First and foremost, it is us
> >>> hackers that use this device for now and are supposed to make apps for
> >>> freerunner and all, and we don't have a damn keyboard;). All this
> >>> fancy pancy dictionary based guessing is maybe good for normal people
> >>> writing crappy SMS messages, but not for the current user base, in my
> >>> opinion.
> >> you do - Terminal.kbd layout - it ships with illume. i designed the kbd
> >> engine in illume to allow for straight-through pushing of key presses
> >> without a dict int he way. the Terminal.kbd bypasses dict lookup by just
> >> emitting keysyms as opposed to strings. don't like the keys on that .kbd?
> >> edit the .kbd file. change it yourself! its just text!
> >
> > Im planning to develop an application, where is a table, and in each column
> > I want different keyboard layout with different dictionary.
> >
> > Is it possible to change layout and dictionary on the fly? (ie.
> > entering in another text input field).
> >
> > The application would be something, in the first column is only
> > numbers, so I want a keyboard
> > with [0..9-.] buttons, and accept only numbers. In the second column I
> > want to write down what I see (microwave, lamp, soldering iron, etc)
> > and in the third column I want to write the trademark of it (sony,
> > samsung, philips, weller, etc) so I want to change the keyboard
> > between
> > numeric and qwerty, and I want to change the dictionary as of input text
> > field.
> >
> > Is it doable? If so where to start? I know python, and would be glad
> > to see some debian/ubuntu guide how to start programming in efl. (or
> > is it a complete development virtualbox/qemu image? it was discussions
> > about some time ago).
> 
> this is be doable. keyboard application can receive message for client,
> message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE
> and message data is one of:
>   - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_OFF
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_ON
>   - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_ALPHA
>   - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_NUMERIC
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_PIN
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_PHONE_NUMBER
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_HEX
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_TERMINAL
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_PASSWORD
> 
> (I don't know where this list came from, is there some specification or 
> recommendation for virtual keyboard application implementation?)

well ecore_x has a small wrapper for this stuff - but its basically simple x
properties and atoms - i just came up with a list of types of input fields i
could think of and put them in the list. this can be expanded without problems.

> so, the application just have to send one of those messages when 
> entering a field or another.

it's actually a property on the window - but yes. just asking for a "kind of
keyboard" is what the app can do - then the keyboard need to do whatever it
sees fit to honor that request. you cant explicitly select a dictionary though.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Rui Miguel Silva Seabra]

On Tue, Jan 06, 2009 at 12:34:28PM +0100, leona...@lilik.it wrote:
> Hi Raster,
> thanks for the explanation.
> 
> > anyway. i hope this helps people understand how it works. someone can throw
> > this onto the wiki if they like. this is the code i wrote for the illume kbd
> 
> I've summarized this in a page:
> 
> http://wiki.openmoko.org/wiki/Illume_keyboard
> 
> it's cool, you should really patent it!
> :-)))

Please die a slow and painful death for suggesting that. [1]

Rui

[1] unless you were really just making a very bad taste joke :)

-- 
Or is it?
Today is Sweetmorn, the 6th day of Chaos in the YOLD 3175
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Rui Miguel Silva Seabra]

On Tue, Jan 06, 2009 at 04:17:06PM +1100, Carsten Haitzler wrote:
> > All of them have nice big buttons and share a simple layout. The FR's 
> > screen is big enough even in portrait mode to accommodate a keyboard 
> > like this. The Illume keyboard, as excellent as it is (thanks Raster!!), 
> > is fiddly to use without a stylus. I would like to not have to use a 
> > stylus to compose notes/emails/sms. For terminal use (and using VI) a 
> > more complete k/b is of course justified, but for everyday use we need a 
> > nice finger keyboard.
> 
> with dictionary correction the illume keyboard (and the qtopia one) in normal
> plain qwerty for writing notes and emails and sms's work just great - i've 
> used
> them walking down the street and i can type better on it than i can on my rokr
> e6 WITH a stylus. in fact my n800 with a landscape 4.3" screen is almost
> equivalent in usability (it doesnt dictionary correct).

I agree, I used it today to take notes at a meeting. In vi :)

Rui

-- 
Keep the Lasagna flying!
Today is Sweetmorn, the 6th day of Chaos in the YOLD 3175
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Digital Pioneer]

>
>  Maybe it would be better to have a full-screen input mode where you can
> see what will be typed (maybe keep the rightmost 20-30 characters of the
> string visible in the keyboard app, then actually pass it to the program
> when leaving 'full-screen' mode or pressing 'enter', etc). That still allows
> you to see what you are typing with a full-screen keyboard (which is what it
> seems most people are wanting from the transparency).
>
I think that would be good, though things like tab-completion have to be
considered when inputting to a separate field and dumping the result when
finished.

>From Petr:

> actually i tried it now and even with pure "h e l l o" i got to see
> "Gallo, jello, troop, tempo" and was puzzled as you did... then i
> pressed the ^ icon on the left and learned (again) something new :) try
> it!

Unfortunately, that's the list I was referring to. :( I scrolled through the
entire list (there were probably 15 words) and Hello was not present. Seeing
as the letters I hit wrong were adjacent to the target letter, and I would
say "Hello" is far more common than "Gallo", I was really stunned.
Nevertheless, as has been pointed out... Keyboards like that are excellent
for SMS and whatnot... But when it comes to using a terminal, they are
really not very useful.
On a slightly other topic, I've noticed the programs in my phone stack (such
as creating contacts) are smart about when to have the keyboard up. They
automatically bring it up when you visit a page with text inputs. The
terminal needs this feature badly, but many other apps could use this little
bit of intuitiveness as well.

-- 
Thanks,

The Digital Pioneer
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Eldon Koyle]

On  Jan 06 16:59+0100, kimaidou wrote:
> Hi Kieran,
> +1 for your idea : a toggle fullscreen button would be a great improvement.
> I still consider a transparent keyboard will be a good stuff too. By
> transparent, I don't mean "you can click on the interface under" , I mean
> "you can see what you are writting under the keyboard, but cannot have an
> action on the things under". With you "toggle fullscreen" button, the
> transparent keyboard would be an improvement.


  A 'transparent' keyboard would have a high 'coolness' factor, but I
think it would be hard to really see what you are typing (not to mention
the technical limitations pointed out by rasterman).

  Maybe it would be better to have a full-screen input mode where you
can see what will be typed (maybe keep the rightmost 20-30 characters of
the string visible in the keyboard app, then actually pass it to the
program when leaving 'full-screen' mode or pressing 'enter', etc). That
still allows you to see what you are typing with a full-screen keyboard
(which is what it seems most people are wanting from the transparency).

  Extra points could be awarded for allowing applications to give the
keyboard app a description of the 'active' field to be displayed
in a 'full-screen' mode.

-- 
Eldon Koyle
-- 
The graveyards are full of indispensable men.
-- Charles de Gaulle

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Petr Vanek]

of the explanation of Illume's error-corrective keyboard,
>and it sounded so great, I went and tried it. However, when everything
>except "Hello" was listed when I typed "hdllo" and "hwllo" I gave up
>on it. :( Also, it DESPERATELY needs a reset button to start over on
>the word, if it's not in the list.

actually i tried it now and even with pure "h e l l o" i got to see
"Gallo, jello, troop, tempo" and was puzzled as you did... then i
pressed the ^ icon on the left and learned (again) something new :) try
it!


Petr



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Digital Pioneer]

I also am somewhat surprised by the lack of an excellent code-friendly
keyboard. I use QWO because it actually has the capability of syntactical
symbols and is relatively finger-friendly. Still, sometimes you just can't
beat good ol' fashioned QWERTY. I like the idea, though, of a keyboard that
takes up the entire screen with just a little space at the top to see what
you're typing, and once you've finished you can dump the whole mess into
whatever textbox is focused. A lot more real-estate that way. It doesn't
have to be transparent either.

I read most of the explanation of Illume's error-corrective keyboard, and it
sounded so great, I went and tried it. However, when everything except
"Hello" was listed when I typed "hdllo" and "hwllo" I gave up on it. :(
Also, it DESPERATELY needs a reset button to start over on the word, if it's
not in the list.

-- 
Thanks,

The Digital Pioneer
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

Hi Kieran,
+1 for your idea : a toggle fullscreen button would be a great improvement.
I still consider a transparent keyboard will be a good stuff too. By
transparent, I don't mean "you can click on the interface under" , I mean
"you can see what you are writting under the keyboard, but cannot have an
action on the things under". With you "toggle fullscreen" button, the
transparent keyboard would be an improvement.

2009/1/6 Kieran Fleming 

>
> The most interesting thing about this mockup for me is that it doesn't
> try to make the rest of the UI usable. It reminds me of this keyboard:
> http://www.spbsoftwarehouse.com/products/keyboard/screenshots/100.png
> Where the entire screen is a keyboard.
> Perhaps a good way to get this idea working would be to have a
> fullscreen button on the existing keyboard so you can toggle it when you
> want to.
>
> Kieran Fleming
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Mathieu Rochette]

Laszlo KREKACS wrote:
> Hi!
>
>>> First and foremost, it is us
>>> hackers that use this device for now and are supposed to make apps for
>>> freerunner and all, and we don't have a damn keyboard;). All this
>>> fancy pancy dictionary based guessing is maybe good for normal people
>>> writing crappy SMS messages, but not for the current user base, in my
>>> opinion.
>> you do - Terminal.kbd layout - it ships with illume. i designed the kbd 
>> engine
>> in illume to allow for straight-through pushing of key presses without a dict
>> int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as
>> opposed to strings. don't like the keys on that .kbd? edit the .kbd file.
>> change it yourself! its just text!
>
> Im planning to develop an application, where is a table, and in each column
> I want different keyboard layout with different dictionary.
>
> Is it possible to change layout and dictionary on the fly? (ie.
> entering in another text input field).
>
> The application would be something, in the first column is only
> numbers, so I want a keyboard
> with [0..9-.] buttons, and accept only numbers. In the second column I
> want to write down what I see (microwave, lamp, soldering iron, etc)
> and in the third column I want to write the trademark of it (sony,
> samsung, philips, weller, etc) so I want to change the keyboard
> between
> numeric and qwerty, and I want to change the dictionary as of input text 
> field.
>
> Is it doable? If so where to start? I know python, and would be glad
> to see some debian/ubuntu guide how to start programming in efl. (or
> is it a complete development virtualbox/qemu image? it was discussions
> about some time ago).

this is be doable. keyboard application can receive message for client,
message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE
and message data is one of:
  - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_OFF
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_ON
  - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_ALPHA
  - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_NUMERIC
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_PIN
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_PHONE_NUMBER
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_HEX
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_TERMINAL
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_PASSWORD

(I don't know where this list came from, is there some specification or 
recommendation for virtual keyboard application implementation?)

so, the application just have to send one of those messages when 
entering a field or another.

Mathieu.
>
> Thank you in advance.
>
> Laszlo
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Marc Bantle]

Carsten Haitzler (The Rasterman) schrieb:
>>> ok. let me draw u a keyboard (or part of it):
>>>
>>>   q w e r t y u i o p
>>>a s d f g h j k l
>>> z x c v b n m
>>>   
>> Excellent! Better than any info currently on the WIKI (I could only find
>> reference to the qtopia keyboard and it's usage). Would you mind if I or
>> somebody else put this into the WIKI?
>> 
>
> someone just did... leonardo:
>
> http://wiki.openmoko.org/wiki/Illume_keyboard (well he put a link to it) - 
> feel
> free to just copy and paste it out or re-type/edit/whatever as i said at the
> bottom - throw it up on the wiki :) i'm just here to spew forth mindless 
> babble
> about what i know of the internals of code i wrote. :) you guys can make it
> into some usable document! that's teamwork! i babble incoherently. you guys
> make it coherent :)
>   
And please don't miss to merge and link it with [1] to avoid redundancy 
or conflicts.

Thanks, Marc


[1] 
http://wiki.openmoko.org/wiki/Illume#How_to_use_.28Raster.27s.29_keyboard_.3F

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Kieran Fleming]

On Tue, 2009-01-06 at 01:51 +0100, Pascal d'Hermilly wrote:
> With 2008.12 release, a well working finger-friendly keyboard is the 
> most critical missing feature for me.
> I've made a mockup of a keyboard that I think would make things a lot 
> easier to type.
> http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
> 
> I don't have the skills to code this, but please. I really need a good 
> keyboard to be able to use my openmoko.
> 
> Best regards from Pascal, Denmark
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

The most interesting thing about this mockup for me is that it doesn't
try to make the rest of the UI usable. It reminds me of this keyboard:
http://www.spbsoftwarehouse.com/products/keyboard/screenshots/100.png
Where the entire screen is a keyboard.
Perhaps a good way to get this idea working would be to have a
fullscreen button on the existing keyboard so you can toggle it when you
want to.

Kieran Fleming


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Laszlo KREKACS]

Hi!

>> First and foremost, it is us
>> hackers that use this device for now and are supposed to make apps for
>> freerunner and all, and we don't have a damn keyboard;). All this
>> fancy pancy dictionary based guessing is maybe good for normal people
>> writing crappy SMS messages, but not for the current user base, in my
>> opinion.
>
> you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine
> in illume to allow for straight-through pushing of key presses without a dict
> int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as
> opposed to strings. don't like the keys on that .kbd? edit the .kbd file.
> change it yourself! its just text!

Im planning to develop an application, where is a table, and in each column
I want different keyboard layout with different dictionary.

Is it possible to change layout and dictionary on the fly? (ie.
entering in another text input field).

The application would be something, in the first column is only
numbers, so I want a keyboard
with [0..9-.] buttons, and accept only numbers. In the second column I
want to write down what I see (microwave, lamp, soldering iron, etc)
and in the third column I want to write the trademark of it (sony,
samsung, philips, weller, etc) so I want to change the keyboard
between
numeric and qwerty, and I want to change the dictionary as of input text field.

Is it doable? If so where to start? I know python, and would be glad
to see some debian/ubuntu guide how to start programming in efl. (or
is it a complete development virtualbox/qemu image? it was discussions
about some time ago).

Thank you in advance.

Laszlo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 12:28:09 - (UTC) "Jan Henkins" 
babbled:

> Hello Raster,
> 
> 
> On Tue, January 6, 2009 09:56, Carsten Haitzler wrote:
> 
> > ok. let me draw u a keyboard (or part of it):
> >
> >   q w e r t y u i o p
> >a s d f g h j k l
> > z x c v b n m
> 
> 
> Excellent! Better than any info currently on the WIKI (I could only find
> reference to the qtopia keyboard and it's usage). Would you mind if I or
> somebody else put this into the WIKI?

someone just did... leonardo:

http://wiki.openmoko.org/wiki/Illume_keyboard (well he put a link to it) - feel
free to just copy and paste it out or re-type/edit/whatever as i said at the
bottom - throw it up on the wiki :) i'm just here to spew forth mindless babble
about what i know of the internals of code i wrote. :) you guys can make it
into some usable document! that's teamwork! i babble incoherently. you guys
make it coherent :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Jan Henkins]

Hello Raster,


On Tue, January 6, 2009 09:56, Carsten Haitzler wrote:

> ok. let me draw u a keyboard (or part of it):
>
>   q w e r t y u i o p
>a s d f g h j k l
> z x c v b n m


Excellent! Better than any info currently on the WIKI (I could only find
reference to the qtopia keyboard and it's usage). Would you mind if I or
somebody else put this into the WIKI?

-- 
Regards,
Jan Henkins


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Alberto Morales]

El Martes, 6 de Enero de 2009, Carsten Haitzler escribió:
> [...] my bet is more people are more proficient at qwerty than
> at abcdefgh... (those really proficient at abcdefgh are ALSO likely
> to be really good at qwerty too - the teenagers and young people
> totally addicted to smsing eachother on their phones probably also
> are pretty good at tapping away on their instant messengers on their
> laptops/desktops - but thats just my bet on the audience).

I agree. I feel better with something like this... but using two 
fingers.

[ q w e ]  [ r t ]  [ y u ]  [ i o p ]
[ a s d ]  [ f g ]  [ h j ]  [ k l ; ]
[ z x c ]  [ v b ]  [ n m ]  [ , . / ]
   [space ]  

This one is quicker than previous, but the number of dictionary 
suggestions has to be studied.

[ q w e r t ]  [ y u i o p ]
[ a s d f g ]  [ h j k l ; ]
[ z x c v b ]  [ n m , . / ]
  [space ]

For example, the word "house"... not too bad results.

$ egrep "^[hjkl;][yuiop][yuiop][asdfg][qwert]$" 
/usr/share/dict/american-english 
hoist
house
joist
joust
loose
louse

Perhaps this one would be better for one finger only:

[ q w e ]  [ r t y u ]  [ i o p ]
[ a s d ]  [ f g h j ]  [ k l ; ]
[ z x c ]  [ v b n m ]  [ , . / ]
[space ]  

$ egrep "^[fghj][iop][rtyu][asd][qwe]$" /usr/share/dict/american-english 
gorse
horde
horse
house

-- 

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 12:46:41 +0100 kimaidou  babbled:

> SorrI just sent it to fast: here is the end of my message :
> 
> 2009/1/6 kimaidou 
> 
> > Hi
> >
> > I like the idea to create a new layout with the well known phone
> > arrangement :
> > [] [abc] [def]
> > [ghi] [jkl] [mno]
> > [pqrs] [tuv] [wxyz]
> 
> 
> Do you think it will help to type faster with illume keyboard ?

no. as its the same # of keys - same letters, simply laid out differently.
those used to phone keypads who like them much more than qwerty may prefer it -
those used to qwerty will do nothing but swear and curse. my bet is more people
are more proficient at qwerty than at abcdefgh... (those really proficient at
abcdefgh are ALSO likely to be really good at qwerty too - the teenagers and
young people totally addicted to smsing eachother on their phones probably
also are pretty good at tapping away on their instant messengers on their
laptops/desktops - but thats just my bet on the audience).

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

SorrI just sent it to fast: here is the end of my message :

2009/1/6 kimaidou 

> Hi
>
> I like the idea to create a new layout with the well known phone
> arrangement :
> [] [abc] [def]
> [ghi] [jkl] [mno]
> [pqrs] [tuv] [wxyz]


Do you think it will help to type faster with illume keyboard ?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

Hi

I like the idea to create a new layout with the well known phone arrangement
:
[] [abc] [def]
[ghi] [jkl] [mno]
[pqrs]
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 12:34:28 +0100 "leona...@lilik.it" 
babbled:

> 
> Hi Raster,
> thanks for the explanation.
> 
> > anyway. i hope this helps people understand how it works. someone can throw
> > this onto the wiki if they like. this is the code i wrote for the illume kbd
> 
> I've summarized this in a page:
> 
> http://wiki.openmoko.org/wiki/Illume_keyboard
> 
> it's cool, you should really patent it!
> :-)))

i'd rather not. 1. trollt.. err.. nokia deserve thanks for the core inspiration
and initial work on their one - i didn't know how the code worked until later
but i nutted out how it probably should work just by poking at it. so if anyone
deserves a patent - it's them. 2. i'd rather this be well publicised and "out
there" code in the public eye - so the idea is widespread and well known - thus
serves as prior art pretty much making it impossible for someone to come along
and patent the idea and make things a pain. get the ideas out there in code -
in the public eye with a trail of history so it's available for everyone to see
and use. if someone implements a better kbd but steals the same idea - i'm
sticking my thumbs up going "good on-ya mate!" i want users and the community
to benefit. 3. i fundamentally disagree with software patents - or at least the
way they have been implemented. the vast majority i have seen are neither novel
nor "non-obvious to someone skilled in the art". most are incredibly mundane
straightforward things to "someone skilled in the art" and the system has been
abused to further greed and misplace credit in the hands of those with more
lawyers, not those who innovate the most or the best. be that as it may - the
system is there and we are stuck with it. i'm not a crusader trying to bring it
down - i don't have the time. got code to write and ideas to make happen :) but
i hope in my little way i can shake my fist at the system and go "here... prior
art. take that!". i'll let others fight the good fight in trying to reform the
patent system. i'm just rattling my chains and moaning in my corner...
'brains! brains! braiins! need moore brains!' :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[leona...@lilik.it]

Hi Raster,
thanks for the explanation.

> anyway. i hope this helps people understand how it works. someone can throw
> this onto the wiki if they like. this is the code i wrote for the illume kbd

I've summarized this in a page:

http://wiki.openmoko.org/wiki/Illume_keyboard

it's cool, you should really patent it!
:-)))

ciao,
leonardo.

-- 
http://leonardo.lilik.it
Key fingerprint = 2C20 A587 05AC 42E5 1292  D0D4 3EED CFB5 52FD AD1E

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 11:53:37 +0100 Mathieu Rochette  babbled:

> Shashank Bharadwaj wrote:
> > On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler
> > mailto:ras...@rasterman.com>> wrote:
> >
> > On Tue, 06 Jan 2009 02:46:15 + Jan Henkins  > > babbled:
> >
> >  > Hello there,
> >  >
> >  > Pascal d'Hermilly wrote:
> >  > > With 2008.12 release, a well working finger-friendly keyboard
> > is the
> >  > > most critical missing feature for me.
> >  > > I've made a mockup of a keyboard that I think would make things
> > a lot
> >  > > easier to type.
> >  > > http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
> >
> >
> > I think, the current Raster's Keyboard great for potrait mode. For
> > landscape mode(i.e holding neo sideways) however, the keyboard does not
> > utilize the extra space. What we need is, imho, a keyboard that would
> > increase in size to take up the extra space in this landscape mode. That
> > way we'll be able to type even faster. If we could add that fuctionality
> > to raster's keyboard, then it'd be just great.
> >
> if you start the keyboard in landscape mode, it does utilize all 
> available place and it's great :)
> (in keyboard settings, just select non and then default while in 
> landscape mode)
> 
> Another thing, I can't test it from office, but, is it possible to have 
> multiple at the same position, if so one could make a t9 "like" layout
> just put, abc on the same position, def, on another, etc.
> would that be possible?

no it's not possible as they'd overlap and you'd not see the ones underneath -
BUT you could do just as well with:

[...@][!][?][.] [ a][ b][ c] [ d][ e][ f]

[ g][ h][ i] [ j][ k][ l] [ m][ n][ o]

[p][q][r][s] [ t][ u][ v] [w][x][y][z]

[ *  ][] [ +  ][ .  ] [ #  ][ &  ] 

(make it a bit taller). :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 23:55:13 +1300 "Robin Paulson" 
babbled:

> 2009/1/6 The Rasterman Carsten Haitzler :
> > you do - Terminal.kbd layout - it ships with illume. i designed the kbd
> > engine in illume to allow for straight-through pushing of key presses
> > without a dict int he way. the Terminal.kbd bypasses dict lookup by just
> > emitting keysyms as
> 
> following on from this, would a hybrid of the two (the terminal kb no
> guesses, and the dictionary lookup kb) be possible? it can be very
> frustrating to think a long word will be in the dictionary, type it,
> find it's not in the dictionary, and have to delete it, switch to the
> terminal kb and type it again.
> 
> when the list of possible words comes up, it would be very useful to
> have the kb give the exact sequence of letters, as typed, as one
> option, alongside the dictionary guesses

hold and press -to zoom and select keys. once in the dict - its in. and yes its
possible to make a version of the basic (Default) qwerty that doesnt use the
dict - just do a .kbd file- look at the terminal and default kbd files and work
it out - its easy to figure that one out :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Robin Paulson]

2009/1/6 The Rasterman Carsten Haitzler :
> you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine
> in illume to allow for straight-through pushing of key presses without a dict
> int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as

following on from this, would a hybrid of the two (the terminal kb no
guesses, and the dictionary lookup kb) be possible? it can be very
frustrating to think a long word will be in the dictionary, type it,
find it's not in the dictionary, and have to delete it, switch to the
terminal kb and type it again.

when the list of possible words comes up, it would be very useful to
have the kb give the exact sequence of letters, as typed, as one
option, alongside the dictionary guesses

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Mathieu Rochette]

Shashank Bharadwaj wrote:
> On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler
> mailto:ras...@rasterman.com>> wrote:
>
> On Tue, 06 Jan 2009 02:46:15 + Jan Henkins  > babbled:
>
>  > Hello there,
>  >
>  > Pascal d'Hermilly wrote:
>  > > With 2008.12 release, a well working finger-friendly keyboard
> is the
>  > > most critical missing feature for me.
>  > > I've made a mockup of a keyboard that I think would make things
> a lot
>  > > easier to type.
>  > > http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
>
>
> I think, the current Raster's Keyboard great for potrait mode. For
> landscape mode(i.e holding neo sideways) however, the keyboard does not
> utilize the extra space. What we need is, imho, a keyboard that would
> increase in size to take up the extra space in this landscape mode. That
> way we'll be able to type even faster. If we could add that fuctionality
> to raster's keyboard, then it'd be just great.
>
if you start the keyboard in landscape mode, it does utilize all 
available place and it's great :)
(in keyboard settings, just select non and then default while in 
landscape mode)

Another thing, I can't test it from office, but, is it possible to have 
multiple at the same position, if so one could make a t9 "like" layout
just put, abc on the same position, def, on another, etc.
would that be possible?

Mathieu.
> Just my INR 0.02.
>
> --
> Regards
> Shashank
> As our circle of knowledge expands, so does the circumference of
> darkness surrounding it - Albert Einstein
>
>
> 
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Leonti Bielski]

I like the illume keyboard! I like it a lot.
Word matching is working for me very well even for thumb. I get exact
words with my finger in a majority of cases.

Dictionaries. It seems like a lot of people blame Raster's keyboard
for not getting word matches because of the lack of dictionary. Do you
really expect Rasterman to make dictionaries for every language?
Dictionary format is very simple.

In conclusion - for our screen, from all possible qwerty keyboards -
Raster's is the best one. Maybe some other inpout method would be
good, but as for keyboard it's actually very very impressive.

Leonti

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 11:39:02 +0100 "arne anka"  babbled:

> >> > no, t9 is patented in it's entirety.
> >>
> >> what exactly is patented that could not be reimplemented?
> >>
> >> - the system of numbers and characters per key is afaik a well known
> >> standard (and dating from long before the mobile era)
> >> - hitting the key several times to select a specific symbol was done  
> >> long
> >> before t9 came up
> >> - completing a word from a dictionary based on the already available
> >> string is done by several keyboard apps (even xvkbd afaik) w/o violating
> >> any patents
> >
> > the last bit is patented. matching it to a dictionary (when combined  
> > with the
> > first 2). this is the patent. when combined with a numberpad and key
> > combinations per number - to use a dictionary to auto-guess the key you  
> > wanted
> > without having to cycle through all keys with multiple presses on a key.
> 
> sounds to my like a combination of prior art and triviality -- but  
> probably no one has time or money to dispute it ...

they do. they have. and they have lost. patent has withstood the court system.
and that cost them dearly. google it. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 13:37:41 +0300 Paul Fertser  babbled:

> Hi,
> 
> Carsten Haitzler (The Rasterman)  writes:
> >> what exactly is patented that could not be reimplemented?
> ...
> >> - completing a word from a dictionary based on the already available  
> >> string is done by several keyboard apps (even xvkbd afaik) w/o violating  
> >> any patents
> >
> > the last bit is patented. matching it to a dictionary (when combined with
> > the first 2). this is the patent. when combined with a numberpad and key
> > combinations per number - to use a dictionary to auto-guess the key you
> > wanted without having to cycle through all keys with multiple presses on a
> > key.
> 
> But isn't it a "software patent" and therefore unenforceable in any
> sane jurisdiction?
> 
> It seems many people just can't believe how bad "software patents" are
> if they can be enforced. So bad it's hard to imagine.

you might be surprised how many jurisdictions its enforceable in. several
companies have been taken to court and lost over this patent - having to pay
up. and they had to pay up big-time. millions of $. now you can do your own
software for your own "software patents can go suck a duck" world - but the
moment that software goes to major markets in the world and is distributed
and/or used - people are in danger of litigation over a successfully defended
patent. and even worse - they are up for extra damages as you now KNOW about
the patent - if you don't know you get off lighter. the moment it can be shown
you knew and violated it anyway... you are in deep trouble.

yes - software patents suck - but they are a reality of life unfortunately. i
wish they didn't exist. even places where software patents don't apply - they
are normally enforceable when COMBINED with hardware. so that means OM can't
ever ship a product with such an input system so it's useless to om as its
combined with hardware - even if it's an extra download later - OM is directly
involved in development of the software and hosting repositories of software to
download etc. etc. so they are playing with fire even having anything to do
with such an input method.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[arne anka]

>> > no, t9 is patented in it's entirety.
>>
>> what exactly is patented that could not be reimplemented?
>>
>> - the system of numbers and characters per key is afaik a well known
>> standard (and dating from long before the mobile era)
>> - hitting the key several times to select a specific symbol was done  
>> long
>> before t9 came up
>> - completing a word from a dictionary based on the already available
>> string is done by several keyboard apps (even xvkbd afaik) w/o violating
>> any patents
>
> the last bit is patented. matching it to a dictionary (when combined  
> with the
> first 2). this is the patent. when combined with a numberpad and key
> combinations per number - to use a dictionary to auto-guess the key you  
> wanted
> without having to cycle through all keys with multiple presses on a key.


sounds to my like a combination of prior art and triviality -- but  
probably no one has time or money to dispute it ...

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Paul Fertser]

Hi,

Carsten Haitzler (The Rasterman)  writes:
>> what exactly is patented that could not be reimplemented?
...
>> - completing a word from a dictionary based on the already available  
>> string is done by several keyboard apps (even xvkbd afaik) w/o violating  
>> any patents
>
> the last bit is patented. matching it to a dictionary (when combined with the
> first 2). this is the patent. when combined with a numberpad and key
> combinations per number - to use a dictionary to auto-guess the key you wanted
> without having to cycle through all keys with multiple presses on a
> key.

But isn't it a "software patent" and therefore unenforceable in any
sane jurisdiction?

It seems many people just can't believe how bad "software patents" are
if they can be enforced. So bad it's hard to imagine.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Jan Henkins]

Hello Xavier,

On Tue, January 6, 2009 09:07, Xavier Cremaschi wrote:
>> 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.

In practice this did not work for me. Reasons for this is partly my lack
of proficiency with the likes of the qtopia k/b, and partly because I type
in multiple languages (one being Afrikaans, which does not have a
dictionary yet, something I would like to do a bit of work on myself a bit
later). A stock finger-friendly qwerty layout without dictionary support
works better in a situation like this.

-- 
Regards,
Jan Henkins


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 11:20:12 +0100 "arne anka"  babbled:

> > no, t9 is patented in it's entirety.
> 
> what exactly is patented that could not be reimplemented?
> 
> - the system of numbers and characters per key is afaik a well known  
> standard (and dating from long before the mobile era)
> - hitting the key several times to select a specific symbol was done long  
> before t9 came up
> - completing a word from a dictionary based on the already available  
> string is done by several keyboard apps (even xvkbd afaik) w/o violating  
> any patents

the last bit is patented. matching it to a dictionary (when combined with the
first 2). this is the patent. when combined with a numberpad and key
combinations per number - to use a dictionary to auto-guess the key you wanted
without having to cycle through all keys with multiple presses on a key.

> so, what does t9 do that's not available already?
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 12:02:40 +0100 Esben Stien  babbled:

> Pascal d'Hermilly  writes:
> 
> > a well working finger-friendly keyboard is the most critical missing
> > feature for me.
> 
> Yes, I find this issue very strange. First and foremost, it is us
> hackers that use this device for now and are supposed to make apps for
> freerunner and all, and we don't have a damn keyboard;). All this
> fancy pancy dictionary based guessing is maybe good for normal people
> writing crappy SMS messages, but not for the current user base, in my
> opinion.

you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine
in illume to allow for straight-through pushing of key presses without a dict
int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as
opposed to strings. don't like the keys on that .kbd? edit the .kbd file.
change it yourself! its just text! i tackled both sides of the problem in 1 bit
of code. if you want you can install and use the matchbox keyboard or the
matchbox numberpad keyboard too- they both work. they need a little extra
packaging with a .desktop file - but they are selectable. i tried to cover
pretty much everything anyone could want - an internal built-in kbd capable of
both dictionary fixup entry and simple straight-through terminal keyboard, able
to have that just disabled in favor of an external keyboard window provided by
any process, as well as protocols that are robust for hinting if you want
keyboard entry or not and what kind of entry (numeric, password, terminal) etc.
i've laid a lot of the groundwork and filled in a lot of the boxes too - can't
expect me to do EVERYTHING for EVERYONE... but i tried to cover a good
smattering.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[arne anka]

> no, t9 is patented in it's entirety.

what exactly is patented that could not be reimplemented?

- the system of numbers and characters per key is afaik a well known  
standard (and dating from long before the mobile era)
- hitting the key several times to select a specific symbol was done long  
before t9 came up
- completing a word from a dictionary based on the already available  
string is done by several keyboard apps (even xvkbd afaik) w/o violating  
any patents

so, what does t9 do that's not available already?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 10:14:19 +0100 kimaidou  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 
> 
> > > 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@lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

Woua ! THAT is a complete explanation ! It shows well the complexity and
power of the illume keyboard method. I apologize for not having well
understand this before.
I will now definitely use the keyboard, and improve my dictionnary as I
type.
Thanks a lot for the complete explanation



2009/1/6 The Rasterman Carsten Haitzler 

> On Tue, 6 Jan 2009 09:50:38 +0100 kimaidou  babbled:
>
> > Hi all,
> >
> > I am glad people (re-)start to talk about keyboards.
> >
> > 2 points:
> >
> > * Another great improvement compared to the iphone, illume, etc. ones,
> would
> > be to have a transparent keyboard, using the whole screen, but allowing
> to
> > see through it. Of course we need the transparency % to be changed by the
> > user. What about the technical feasibility of that ? Would it be possible
> ?
> > I thing for example about the Qwo keyboard (
> > http://www.opkg.org/package_84.html ) which would be very finger
> friendly in
> > full screen (like the other one)
>
> not possible without compositing. not to mention the absolute HORROR of now
> having to mix keyboard input with controlling the apps under it - which is
> it u
> do? press the key or the "ok" button thats visible thru the key?
> compositing is
> not a viable thing on the freerunner - u'll need a much lower res to make
> it
> sane and even then it'll be really pushing it at qvga on the 2442.
>
> > * I don't get how the dictionnary (illume and qtopia) actually helps to
> > write some word. In mobile phones, on which you have only 9 numbers to
> type,
> > so 3 letters by number, the "T9" dictionnary was really helpfull, because
> it
> > showed a list of words possible with the combination of the letters
> entered.
> > I could actually write sms faster with only 9 keys than now with a
> complete
> > qwerty keyboard because the buttons were much bigger and I had only 9
> button
> > to search among. Here with the FR, the "eyes and brain" must locate the
> > desired letter among much more and much smaller keys. And furthermore, I
> > don't see the point with the dictionnary. The dictionnary only shows
> words
> > with the same number of letters as the ones entered. So it does not
> provide
> > a way to easily choose a word (for example, when I type "for" it must
> show
> > "for", "forest", force", etc., but  with the illume keyboard it only
> shows
> > "for" and other useless words like :"big", "fit", die", but", etc.--> not
> > very related to "for" ) People using OpenOffice Writer with the
> > autocompletion activated will understand what I am trying to explain with
> my
> > limited english skills..
>
> ok. let me draw u a keyboard (or part of it):
>
>  q w e r t y u i o p
>   a s d f g h j k l
>z x c v b n m
>
> i want to type "dog". for this example i will only use english as the
> example -
> but it applies to all languages actually. now lets say i press "d" (i want
> to
> type "dog"), then "o" then "g". but look at the keyboard - i may not
> EXACTLY
> hit d, o and g. i probably hit them or something near them, so ad i try and
> hit
> d i may hit e, and i may hit k and not o, and h instead of g, so i actually
> hit:
> "ekh"
>
> that's not "dog"! of course not. but it also is not any word in english (in
> the
> dictionary) so obviously.. it must be wrong. i meant something else. now
> lets
> stand back.
>
> first key i press "e" is near d. it's also near r, s, w, and f. let's write
> the
> "possible" keys i may have intended as a list per keystroke:
> e, d, r, s, w, f
> now for "k" (when i meant "o"):
> k, i, u, j, m, l, o
> and for "h" (when i meant "g"):
> h, y, u, j, n, b, g
>
> ok so now for every keystroke i have a list of possible keys near where i
> pressed that i may have meant (again i have simplified this - in reality
> the
> list of keys per press is more like 10-15 possible keys as it has a large
> search area - this is the fuzz value in the .kbd file - it determines how
> far
> the fuzzy matching should search in virtual keyboard units).
>
> now what we do is start checking all combinations of all the letters per
> key
> stroke, so we first try:
>
> ekh -> wrong
> eih -> wrong
> euh -> wrong
> ejh -> wrong
> emh -> wrong
> elh -> wrong
> eoh -> wrong
> eky -> wrong
> eiy -> wrong
> euy -> wrong
> ejy -> wrong
> emy -> wrong
> ely -> wrong
> eoy -> wrong
> ekh -> wrong
> eiu -> wrong
> euu -> wrong
> eju -> wrong
> emu -> BINGO! a real word!
> elu -> wrong
> eou -> wrong
> ekj -> wrong
> eij -> wrong
> etc.
>
> in the end if you search permutations you'd get a list of words that
> "match"
>
> emu, fig, dig, fly, sky, fog, rig, sob, dog, ... and so on.
>
> now we have a list of words i possibly wanted that match. (its very much
> like
> the 2 == avc, 3 == def, 4 == ghi, 5 == jkl etc. - but its not based on
> mapping
> 26 letters to just 8 numbers on a numberpad - because you have no actual
> numberpad - its just a surface you tap on and you have a co-ordinate where
> you
> press. so you dont NEED to map it that way - you can just pre

Re: Openmoko keyboard mockup

[Esben Stien]

Pascal d'Hermilly  writes:

> a well working finger-friendly keyboard is the most critical missing
> feature for me.

Yes, I find this issue very strange. First and foremost, it is us
hackers that use this device for now and are supposed to make apps for
freerunner and all, and we don't have a damn keyboard;). All this
fancy pancy dictionary based guessing is maybe good for normal people
writing crappy SMS messages, but not for the current user base, in my
opinion.

-- 
Esben Stien is b...@e s  a 
 http://www. s tn m
  irc://irc.  b  -  i  .   e/%23contact
   sip:b0ef@   e e 
   jid:b0ef@n n

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Robin Paulson]

2009/1/6 kimaidou :
> 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, t9 is patented in it's entirety. ms office is not patented as a
whole, although some parts might be - ms do not own the concepts of a
word processor/spreadsheet/presentation editor

as raster and om have shown, there are other great methods to input
text; i'm sure someone can design more decent methods, without ripping

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 09:50:38 +0100 kimaidou  babbled:

> Hi all,
> 
> I am glad people (re-)start to talk about keyboards.
> 
> 2 points:
> 
> * Another great improvement compared to the iphone, illume, etc. ones, would
> be to have a transparent keyboard, using the whole screen, but allowing to
> see through it. Of course we need the transparency % to be changed by the
> user. What about the technical feasibility of that ? Would it be possible ?
> I thing for example about the Qwo keyboard (
> http://www.opkg.org/package_84.html ) which would be very finger friendly in
> full screen (like the other one)

not possible without compositing. not to mention the absolute HORROR of now
having to mix keyboard input with controlling the apps under it - which is it u
do? press the key or the "ok" button thats visible thru the key? compositing is
not a viable thing on the freerunner - u'll need a much lower res to make it
sane and even then it'll be really pushing it at qvga on the 2442.

> * I don't get how the dictionnary (illume and qtopia) actually helps to
> write some word. In mobile phones, on which you have only 9 numbers to type,
> so 3 letters by number, the "T9" dictionnary was really helpfull, because it
> showed a list of words possible with the combination of the letters entered.
> I could actually write sms faster with only 9 keys than now with a complete
> qwerty keyboard because the buttons were much bigger and I had only 9 button
> to search among. Here with the FR, the "eyes and brain" must locate the
> desired letter among much more and much smaller keys. And furthermore, I
> don't see the point with the dictionnary. The dictionnary only shows words
> with the same number of letters as the ones entered. So it does not provide
> a way to easily choose a word (for example, when I type "for" it must show
> "for", "forest", force", etc., but  with the illume keyboard it only shows
> "for" and other useless words like :"big", "fit", die", but", etc.--> not
> very related to "for" ) People using OpenOffice Writer with the
> autocompletion activated will understand what I am trying to explain with my
> limited english skills..

ok. let me draw u a keyboard (or part of it):

  q w e r t y u i o p
   a s d f g h j k l
z x c v b n m

i want to type "dog". for this example i will only use english as the example -
but it applies to all languages actually. now lets say i press "d" (i want to
type "dog"), then "o" then "g". but look at the keyboard - i may not EXACTLY
hit d, o and g. i probably hit them or something near them, so ad i try and hit
d i may hit e, and i may hit k and not o, and h instead of g, so i actually hit:
"ekh"

that's not "dog"! of course not. but it also is not any word in english (in the
dictionary) so obviously.. it must be wrong. i meant something else. now lets
stand back.

first key i press "e" is near d. it's also near r, s, w, and f. let's write the
"possible" keys i may have intended as a list per keystroke:
e, d, r, s, w, f
now for "k" (when i meant "o"):
k, i, u, j, m, l, o
and for "h" (when i meant "g"):
h, y, u, j, n, b, g

ok so now for every keystroke i have a list of possible keys near where i
pressed that i may have meant (again i have simplified this - in reality the
list of keys per press is more like 10-15 possible keys as it has a large
search area - this is the fuzz value in the .kbd file - it determines how far
the fuzzy matching should search in virtual keyboard units).

now what we do is start checking all combinations of all the letters per key
stroke, so we first try:

ekh -> wrong
eih -> wrong
euh -> wrong
ejh -> wrong
emh -> wrong
elh -> wrong
eoh -> wrong
eky -> wrong
eiy -> wrong
euy -> wrong
ejy -> wrong
emy -> wrong
ely -> wrong
eoy -> wrong
ekh -> wrong
eiu -> wrong
euu -> wrong
eju -> wrong
emu -> BINGO! a real word!
elu -> wrong
eou -> wrong
ekj -> wrong
eij -> wrong
etc.

in the end if you search permutations you'd get a list of words that "match"

emu, fig, dig, fly, sky, fog, rig, sob, dog, ... and so on.

now we have a list of words i possibly wanted that match. (its very much like
the 2 == avc, 3 == def, 4 == ghi, 5 == jkl etc. - but its not based on mapping
26 letters to just 8 numbers on a numberpad - because you have no actual
numberpad - its just a surface you tap on and you have a co-ordinate where you
press. so you dont NEED to map it that way - you can just present a qwerty
layout and just search for nearby keys u may have wanted to hit.

anyway - this is the simple version. now.. things get more complex. lets go
over the keys i possible wanted to hit again:

e, d, r, s, w, f
k, i, u, j, m, l, o
h, y, u, j, n, b, g

unlike the numberpas - the set of keys per press is entirely variable based on
what keys are near "within" the fuzz search radius. also unlike a keypad each
key will have a DISTANCE from the point i pressed so i know how far away it is
from the press point - thus the further away - the more unlikely it is i wanted
it. the clos

Re: Openmoko keyboard mockup

[kimaidou]

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 ?

@Xavier : Ah ah, I completely lost this one ! I wil try it now

@ both and others : what about transparency ?

2009/1/6 Xavier Cremaschi 

> > 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@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Xavier Cremaschi]

> 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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Vasili Sviridov]

Good point about T9 kimaidou, but as far as I know the T9 itself is a 
patented technology, and would not be able to appear on Moko officially...


kimaidou wrote:

Hi all,

I am glad people (re-)start to talk about keyboards.

2 points:

* Another great improvement compared to the iphone, illume, etc. ones, 
would be to have a transparent keyboard, using the whole screen, but 
allowing to see through it. Of course we need the transparency % to be 
changed by the user. What about the technical feasibility of that ? 
Would it be possible ? I thing for example about the Qwo keyboard ( 
http://www.opkg.org/package_84.html ) which would be very finger 
friendly in full screen (like the other one)


* I don't get how the dictionnary (illume and qtopia) actually helps 
to write some word. In mobile phones, on which you have only 9 numbers 
to type, so 3 letters by number, the "T9" dictionnary was really 
helpfull, because it showed a list of words possible with the 
combination of the letters entered. I could actually write sms faster 
with only 9 keys than now with a complete qwerty keyboard because the 
buttons were much bigger and I had only 9 button to search among. Here 
with the FR, the "eyes and brain" must locate the desired letter among 
much more and much smaller keys. And furthermore, I don't see the 
point with the dictionnary. The dictionnary only shows words with the 
same number of letters as the ones entered. So it does not provide a 
way to easily choose a word (for example, when I type "for" it must 
show "for", "forest", force", etc., but  with the illume keyboard it 
only shows "for" and other useless words like :"big", "fit", die", 
but", etc.--> not very related to "for" ) People using OpenOffice 
Writer with the autocompletion activated will understand what I am 
trying to explain with my limited english skills..


My 2 cents :) , of course in a constructive way

Kimaidou

2009/1/6 The Rasterman Carsten Haitzler >


On Tue, 6 Jan 2009 11:08:41 +0530 "Shashank Bharadwaj"
mailto:shanka@gmail.com>>
babbled:

> On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler <
> ras...@rasterman.com > wrote:
>
> > On Tue, 06 Jan 2009 02:46:15 + Jan Henkins
mailto:j...@henkins.za.net>>
> > babbled:
> >
> > > Hello there,
> > >
> > > Pascal d'Hermilly wrote:
> > > > With 2008.12 release, a well working finger-friendly
keyboard is the
> > > > most critical missing feature for me.
> > > > I've made a mockup of a keyboard that I think would make
things a lot
> > > > easier to type.
> > > > http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
> >
>
> I think, the current Raster's Keyboard great for potrait mode.
For landscape
> mode(i.e holding neo sideways) however, the keyboard does not
utilize the
> extra space. What we need is, imho, a keyboard that would
increase in size
> to take up the extra space in this landscape mode. That way
we'll be able to
> type even faster. If we could add that fuctionality to raster's
keyboard,
> then it'd be just great.

that's a matter of just fixing the code to handle resizing
appropriately.

--
- Codito, ergo sum - "I code, therefore I am"
--
The Rasterman (Carsten Haitzler)ras...@rasterman.com



___
Openmoko community mailing list
community@lists.openmoko.org 
http://lists.openmoko.org/mailman/listinfo/community




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
  


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

Hi all,

I am glad people (re-)start to talk about keyboards.

2 points:

* Another great improvement compared to the iphone, illume, etc. ones, would
be to have a transparent keyboard, using the whole screen, but allowing to
see through it. Of course we need the transparency % to be changed by the
user. What about the technical feasibility of that ? Would it be possible ?
I thing for example about the Qwo keyboard (
http://www.opkg.org/package_84.html ) which would be very finger friendly in
full screen (like the other one)

* I don't get how the dictionnary (illume and qtopia) actually helps to
write some word. In mobile phones, on which you have only 9 numbers to type,
so 3 letters by number, the "T9" dictionnary was really helpfull, because it
showed a list of words possible with the combination of the letters entered.
I could actually write sms faster with only 9 keys than now with a complete
qwerty keyboard because the buttons were much bigger and I had only 9 button
to search among. Here with the FR, the "eyes and brain" must locate the
desired letter among much more and much smaller keys. And furthermore, I
don't see the point with the dictionnary. The dictionnary only shows words
with the same number of letters as the ones entered. So it does not provide
a way to easily choose a word (for example, when I type "for" it must show
"for", "forest", force", etc., but  with the illume keyboard it only shows
"for" and other useless words like :"big", "fit", die", but", etc.--> not
very related to "for" ) People using OpenOffice Writer with the
autocompletion activated will understand what I am trying to explain with my
limited english skills..

My 2 cents :) , of course in a constructive way

Kimaidou

2009/1/6 The Rasterman Carsten Haitzler 

> On Tue, 6 Jan 2009 11:08:41 +0530 "Shashank Bharadwaj" <
> shanka@gmail.com>
> babbled:
>
> > On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler <
> > ras...@rasterman.com> wrote:
> >
> > > On Tue, 06 Jan 2009 02:46:15 + Jan Henkins 
> > > babbled:
> > >
> > > > Hello there,
> > > >
> > > > Pascal d'Hermilly wrote:
> > > > > With 2008.12 release, a well working finger-friendly keyboard is
> the
> > > > > most critical missing feature for me.
> > > > > I've made a mockup of a keyboard that I think would make things a
> lot
> > > > > easier to type.
> > > > > http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
> > >
> >
> > I think, the current Raster's Keyboard great for potrait mode. For
> landscape
> > mode(i.e holding neo sideways) however, the keyboard does not utilize the
> > extra space. What we need is, imho, a keyboard that would increase in
> size
> > to take up the extra space in this landscape mode. That way we'll be able
> to
> > type even faster. If we could add that fuctionality to raster's keyboard,
> > then it'd be just great.
>
> that's a matter of just fixing the code to handle resizing appropriately.
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 11:08:41 +0530 "Shashank Bharadwaj" 
babbled:

> On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler <
> ras...@rasterman.com> wrote:
> 
> > On Tue, 06 Jan 2009 02:46:15 + Jan Henkins 
> > babbled:
> >
> > > Hello there,
> > >
> > > Pascal d'Hermilly wrote:
> > > > With 2008.12 release, a well working finger-friendly keyboard is the
> > > > most critical missing feature for me.
> > > > I've made a mockup of a keyboard that I think would make things a lot
> > > > easier to type.
> > > > http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
> >
> 
> I think, the current Raster's Keyboard great for potrait mode. For landscape
> mode(i.e holding neo sideways) however, the keyboard does not utilize the
> extra space. What we need is, imho, a keyboard that would increase in size
> to take up the extra space in this landscape mode. That way we'll be able to
> type even faster. If we could add that fuctionality to raster's keyboard,
> then it'd be just great.

that's a matter of just fixing the code to handle resizing appropriately.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Shashank Bharadwaj]

On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler <
ras...@rasterman.com> wrote:

> On Tue, 06 Jan 2009 02:46:15 + Jan Henkins 
> babbled:
>
> > Hello there,
> >
> > Pascal d'Hermilly wrote:
> > > With 2008.12 release, a well working finger-friendly keyboard is the
> > > most critical missing feature for me.
> > > I've made a mockup of a keyboard that I think would make things a lot
> > > easier to type.
> > > http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
>

I think, the current Raster's Keyboard great for potrait mode. For landscape
mode(i.e holding neo sideways) however, the keyboard does not utilize the
extra space. What we need is, imho, a keyboard that would increase in size
to take up the extra space in this landscape mode. That way we'll be able to
type even faster. If we could add that fuctionality to raster's keyboard,
then it'd be just great.

Just my INR 0.02.

-- 
Regards
Shashank
As our circle of knowledge expands, so does the circumference of darkness
surrounding it - Albert Einstein
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 02:46:15 + Jan Henkins  babbled:

> Hello there,
> 
> Pascal d'Hermilly wrote:
> > With 2008.12 release, a well working finger-friendly keyboard is the 
> > most critical missing feature for me.
> > I've made a mockup of a keyboard that I think would make things a lot 
> > easier to type.
> > http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
> >
> > I don't have the skills to code this, but please. I really need a good 
> > keyboard to be able to use my openmoko.
> >   
> 
> I fully agree that we need a proper finger-friendly keyboard. I'm sure 
> that it is planned, and I can sort-of remember that the Matchbox 
> keyboard has big enough keys to be a lot easier to use than the Illume 
> keyboard. Here are some other keyboard examples:
> 
> A weird keyboard on M$ Mobile (yech!):
> http://msmobiles.com/news.php/6630.html
> 
> Iphone keyboard styled like the Macbook Air (now this looks the business!):
> http://www.intomobile.com/2008/07/02/make-your-iphone-virtual-keyboard-look-like-its-macbook-air.html
> 
> Blackberry's Iphone keyboard ripoff:
> http://blogs.zdnet.com/Apple/?p=1996
> 
> All of them have nice big buttons and share a simple layout. The FR's 
> screen is big enough even in portrait mode to accommodate a keyboard 
> like this. The Illume keyboard, as excellent as it is (thanks Raster!!), 
> is fiddly to use without a stylus. I would like to not have to use a 
> stylus to compose notes/emails/sms. For terminal use (and using VI) a 
> more complete k/b is of course justified, but for everyday use we need a 
> nice finger keyboard.

with dictionary correction the illume keyboard (and the qtopia one) in normal
plain qwerty for writing notes and emails and sms's work just great - i've used
them walking down the street and i can type better on it than i can on my rokr
e6 WITH a stylus. in fact my n800 with a landscape 4.3" screen is almost
equivalent in usability (it doesnt dictionary correct).


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Jan Henkins]

Hello there,

Pascal d'Hermilly wrote:
> With 2008.12 release, a well working finger-friendly keyboard is the 
> most critical missing feature for me.
> I've made a mockup of a keyboard that I think would make things a lot 
> easier to type.
> http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
>
> I don't have the skills to code this, but please. I really need a good 
> keyboard to be able to use my openmoko.
>   

I fully agree that we need a proper finger-friendly keyboard. I'm sure 
that it is planned, and I can sort-of remember that the Matchbox 
keyboard has big enough keys to be a lot easier to use than the Illume 
keyboard. Here are some other keyboard examples:

A weird keyboard on M$ Mobile (yech!):
http://msmobiles.com/news.php/6630.html

Iphone keyboard styled like the Macbook Air (now this looks the business!):
http://www.intomobile.com/2008/07/02/make-your-iphone-virtual-keyboard-look-like-its-macbook-air.html

Blackberry's Iphone keyboard ripoff:
http://blogs.zdnet.com/Apple/?p=1996

All of them have nice big buttons and share a simple layout. The FR's 
screen is big enough even in portrait mode to accommodate a keyboard 
like this. The Illume keyboard, as excellent as it is (thanks Raster!!), 
is fiddly to use without a stylus. I would like to not have to use a 
stylus to compose notes/emails/sms. For terminal use (and using VI) a 
more complete k/b is of course justified, but for everyday use we need a 
nice finger keyboard.

-- 
Regards,
Jan Henkins


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community