Talk:Input Method

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Some ideas)
m (R)
 
(One intermediate revision by one user not shown)
Line 50: Line 50:
  
 
Another issue could be '''how to actually integrate the handwriting mode into the user interface'''. I think that the way it works on Palm/TealScript is quite nice, if not outright ideal. Basically, the way it works is: a tap is regarded as a tap if it's quick or if it's obviously a tap-and-hold. But a tap with a "running start" is regarded as a stroke and interpreted as a character, which is then sent to the application (that is, field input or command character).
 
Another issue could be '''how to actually integrate the handwriting mode into the user interface'''. I think that the way it works on Palm/TealScript is quite nice, if not outright ideal. Basically, the way it works is: a tap is regarded as a tap if it's quick or if it's obviously a tap-and-hold. But a tap with a "running start" is regarded as a stroke and interpreted as a character, which is then sent to the application (that is, field input or command character).
 +
 +
== Keyboard ==
 +
 +
Can a keyboard be hooked up to the FreeRunner? [[User:Emesee|Emesee]] 04:23, 5 July 2008 (UTC)

Latest revision as of 05:24, 5 July 2008

Contents

[edit] A method from pocket pc

I've tried using this: http://www.spbsoftwarehouse.com/products/fsk/screenshots.html

It works quite well. EsbenDamgaard 15:17, 21 March 2007 (CET)

[edit] A method from Agenda VR3

The Agenda VR3 was a linux-based PDA, also with no keyboard. Their solution was to provide an onscreen keyboard, but in addition to the A/a/1 buttons to have a button that opened up a pad for handwriting recognition. Early versions used something called 'scribble' but later versions used XMerlin. So that might be an interesting idea.

[edit] Some ideas

What about to use fonts for the Input metod? is it hard? I think that the widget-keyboard could be dynamic. Connect the input with the orphographic vocabulary, so 5 most probable letters will have bigger area( enough for the finger) (fonts are scalable sometimes) As a transparent widget was shown,the bigger-letters can be on the background of the whole keyboard - each letter on its place. And you can find a little place for the button with the most probable word (may be form with variants).


Maybe a landscape QWERTY-Keyboard with one preview text-line would be the best to input text. - maybe later as a transparent version without the textline...


The keyboard should use the accelerometers to automatically detect if a standard or landscape keyboard should be used. Plus, I think that a "tab" key is really usefull when writing in a terminal, so I think it should be placed near the space key (left side).

[edit] Handwriting

KlaymenDK says: I don't want to mess things up, so I keep to the Talk page. Here's my issue: This page seems to be the only one even mentioning handwriting. The article page states that the Input Method Widget supports "both handwriting recognition, and keyboards", yet the rest of the article seems to not discuss handwriting at all.

I propose creating a section called "Handwriting" to contain this topic.

Being a happy user of a Palm T3 with TealScript, I am quite fond of using the stylus for text input, especially in the "write everywhere" mode where one can use the entire screen as an input area.

I believe that handwriting is worthy of consideration because:

  • IMVHO, it is the most efficient method for fast input on small devices.
  • It is agnostic of keyboard layouts and special language variants (I use Norwegian Dvorak).
  • It consumes no screen real estate at all!
  • It does not preclude the use of an ad-hoc on-screen keyboard.
  • It can be used without a stylus (just use a fingernail).

As I see it, there are two main issues:

  1. Is the OpenMoko actually capable of supporting online handwriting recognition?
    Here I mean in terms of processing power and real-time stroke resolution. This is a fundamental and technical aspect I have no way of answering.
  2. Are there any legal blocks to using handwriting recognition?
    It does not seem so; at least, several open source recognition toolkits exist (LipiTK, HRE, CellWriter, Tomoe, others).
    My main concern is if single-stroke characters are covered by Graffiti patents, and if TealPoint Software (TealScript) holds any patents on user-configurable strokes.

Another issue could be how to actually integrate the handwriting mode into the user interface. I think that the way it works on Palm/TealScript is quite nice, if not outright ideal. Basically, the way it works is: a tap is regarded as a tap if it's quick or if it's obviously a tap-and-hold. But a tap with a "running start" is regarded as a stroke and interpreted as a character, which is then sent to the application (that is, field input or command character).

[edit] Keyboard

Can a keyboard be hooked up to the FreeRunner? Emesee 04:23, 5 July 2008 (UTC)

Personal tools

A method from pocket pc

I've tried using this: http://www.spbsoftwarehouse.com/products/fsk/screenshots.html

It works quite well. EsbenDamgaard 15:17, 21 March 2007 (CET)

A method from Agenda VR3

The Agenda VR3 was a linux-based PDA, also with no keyboard. Their solution was to provide an onscreen keyboard, but in addition to the A/a/1 buttons to have a button that opened up a pad for handwriting recognition. Early versions used something called 'scribble' but later versions used XMerlin. So that might be an interesting idea.

Some ideas

What about to use fonts for the Input metod? is it hard? I think that the widget-keyboard could be dynamic. Connect the input with the orphographic vocabulary, so 5 most probable letters will have bigger area( enough for the finger) (fonts are scalable sometimes) As a transparent widget was shown,the bigger-letters can be on the background of the whole keyboard - each letter on its place. And you can find a little place for the button with the most probable word (may be form with variants).


Maybe a landscape QWERTY-Keyboard with one preview text-line would be the best to input text. - maybe later as a transparent version without the textline...


The keyboard should use the accelerometers to automatically detect if a standard or landscape keyboard should be used. Plus, I think that a "tab" key is really usefull when writing in a terminal, so I think it should be placed near the space key (left side).

Handwriting

KlaymenDK says: I don't want to mess things up, so I keep to the Talk page. Here's my issue: This page seems to be the only one even mentioning handwriting. The article page states that the Input Method Widget supports "both handwriting recognition, and keyboards", yet the rest of the article seems to not discuss handwriting at all.

I propose creating a section called "Handwriting" to contain this topic.

Being a happy user of a Palm T3 with TealScript, I am quite fond of using the stylus for text input, especially in the "write everywhere" mode where one can use the entire screen as an input area.

I believe that handwriting is worthy of consideration because:

  • IMVHO, it is the most efficient method for fast input on small devices.
  • It is agnostic of keyboard layouts and special language variants (I use Norwegian Dvorak).
  • It consumes no screen real estate at all!
  • It does not preclude the use of an ad-hoc on-screen keyboard.
  • It can be used without a stylus (just use a fingernail).

As I see it, there are two main issues:

  1. Is the OpenMoko actually capable of supporting online handwriting recognition?
    Here I mean in terms of processing power and real-time stroke resolution. This is a fundamental and technical aspect I have no way of answering.
  2. Are there any legal blocks to using handwriting recognition?
    It does not seem so; at least, several open source recognition toolkits exist (LipiTK, HRE, CellWriter, Tomoe, others).
    My main concern is if single-stroke characters are covered by Graffiti patents, and if TealPoint Software (TealScript) holds any patents on user-configurable strokes.

Another issue could be how to actually integrate the handwriting mode into the user interface. I think that the way it works on Palm/TealScript is quite nice, if not outright ideal. Basically, the way it works is: a tap is regarded as a tap if it's quick or if it's obviously a tap-and-hold. But a tap with a "running start" is regarded as a stroke and interpreted as a character, which is then sent to the application (that is, field input or command character).