Talk:Input Method - Revision history

Emesee: R

2008-07-05T04:24:30Z

Emesee: /* Keyboard */ new section

2008-07-05T04:23:09Z

‎Keyboard: new section

Kattle87: /* Some ideas */

2008-06-18T19:18:56Z

‎Some ideas

KlaymenDK: /* Handwriting */ Added link to Tomoe

2008-04-02T14:36:24Z

‎Handwriting: Added link to Tomoe

KlaymenDK: reordered points

2008-04-02T12:32:34Z

reordered points

KlaymenDK: Added another point.

2008-03-31T00:45:32Z

Added another point.

KlaymenDK: Handwriting

2008-03-31T00:33:40Z

Handwriting

Kriss: /* Some ideas */ landscape keyboard

2007-07-20T13:54:03Z

‎Some ideas: landscape keyboard

Pj at 03:28, 30 April 2007

2007-04-30T03:28:12Z

Mix: Some ideas

2007-04-28T20:13:02Z

Some ideas

← Older revision		Revision as of 04:24, 5 July 2008
Line 53:		Line 53:
	== Keyboard ==		== Keyboard ==

−	Can a keyboard be hooked up to the ~~Freerunner~~? [[User:Emesee\|Emesee]] 04:23, 5 July 2008 (UTC)	+	Can a keyboard be hooked up to the FreeRunner? [[User:Emesee\|Emesee]] 04:23, 5 July 2008 (UTC)

← Older revision		Revision as of 04:23, 5 July 2008
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)

← Older revision		Revision as of 19:18, 18 June 2008
Line 24:		Line 24:

	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...		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 ==		== Handwriting ==

@@ Line 43: / Line 43: @@
 As I see it, there are two main issues:
 # '''Is the OpenMoko actually capable of supporting online handwriting recognition?'''<br>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.
-# '''Are there any legal blocks to using handwriting recognition?'''<br>It does not seem so; at least, several open source recognition toolkits exist ([http://lipitk.sourceforge.net/ LipiTK], [http://playground.sun.com/pub/multimedia/handwriting/hre.html HRE], [http://www.linux.com/feature/120867 CellWriter], [http://www.google.co.uk/search?hl=en&q=open+source+handwriting+recognition others]).<br>My main concern is if single-stroke characters are covered by [http://en.wikipedia.org/wiki/Graffiti_%28Palm_OS%29 Graffiti] patents, and if TealPoint Software ([http://www.tealpoint.com/softscrp.htm TealScript]) holds any patents on  ''user-configurable'' strokes.
+# '''Are there any legal blocks to using handwriting recognition?'''<br>It does not seem so; at least, several open source recognition toolkits exist ([http://lipitk.sourceforge.net/ LipiTK], [http://playground.sun.com/pub/multimedia/handwriting/hre.html HRE], [http://www.linux.com/feature/120867 CellWriter], [http://tomoe.sourceforge.jp Tomoe], [http://www.google.co.uk/search?hl=en&q=open+source+handwriting+recognition others]).<br>My main concern is if single-stroke characters are covered by [http://en.wikipedia.org/wiki/Graffiti_%28Palm_OS%29 Graffiti] patents, and if TealPoint Software ([http://www.tealpoint.com/softscrp.htm 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).

@@ Line 39: / Line 39: @@
 * It ''consumes no screen real estate'' at all!
 * It ''does not preclude the use of an ad-hoc on-screen keyboard''.
-* Can be used without a stylus (just use a fingernail and write big).
+* It can be used without a stylus (just use a fingernail).
 As I see it, there are two main issues:
 # '''Are there any legal blocks to using handwriting recognition?'''<br>It does not seem so; at least, several open source recognition toolkits exist ([http://lipitk.sourceforge.net/ LipiTK], [http://playground.sun.com/pub/multimedia/handwriting/hre.html HRE], [http://www.linux.com/feature/120867 CellWriter], [http://www.google.co.uk/search?hl=en&q=open+source+handwriting+recognition others]).<br>My main concern is if single-stroke characters are covered by [http://en.wikipedia.org/wiki/Graffiti_%28Palm_OS%29 Graffiti] patents, and if TealPoint Software ([http://www.tealpoint.com/softscrp.htm 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).

← Older revision		Revision as of 00:33, 31 March 2008
Line 24:		Line 24:

	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...		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...
		+
		+	== Handwriting ==
		+
		+	[http://wiki.openmoko.org/wiki/User:KlaymenDK 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''.
		+
		+	As I see it, there are two main issues:
		+	# '''Are there any legal blocks to using handwriting recognition?'''<br>It does not seem so; at least, several open source recognition toolkits exist ([http://lipitk.sourceforge.net/ LipiTK], [http://playground.sun.com/pub/multimedia/handwriting/hre.html HRE], [http://www.linux.com/feature/120867 CellWriter], [http://www.google.co.uk/search?hl=en&q=open+source+handwriting+recognition others]).<br>My main concern is if single-stroke characters are covered by [http://en.wikipedia.org/wiki/Graffiti_%28Palm_OS%29 Graffiti] patents, and if TealPoint Software ([http://www.tealpoint.com/softscrp.htm TealScript]) holds any patents on ''user-configurable'' strokes.
		+	# '''Is the OpenMoko actually capable of supporting online handwriting recognition?'''<br>Here I mean in terms of processing power and real-time stroke resolution. This is a technical aspect I have no way of answering.
		+
		+	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).

← Older revision		Revision as of 13:54, 20 July 2007
Line 21:		Line 21:
	And you can find a little place for the button with the most probable word		And you can find a little place for the button with the most probable word
	(may be form with variants).		(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...

← Older revision		Revision as of 03:28, 30 April 2007
Line 5:		Line 5:

	It works quite well. [[User:EsbenDamgaard\|EsbenDamgaard]] 15:17, 21 March 2007 (CET)		It works quite well. [[User:EsbenDamgaard\|EsbenDamgaard]] 15:17, 21 March 2007 (CET)
		+
		+	== A method from Agenda VR3 ==
		+
		+	The [http://www.agendawiki.com 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 [http://www.hellkvist.org/software/ XMerlin]. So that might be an interesting idea.

	== Some ideas ==		== Some ideas ==

← Older revision		Revision as of 20:13, 28 April 2007
Line 5:		Line 5:

	It works quite well. [[User:EsbenDamgaard\|EsbenDamgaard]] 15:17, 21 March 2007 (CET)		It works quite well. [[User:EsbenDamgaard\|EsbenDamgaard]] 15:17, 21 March 2007 (CET)
		+
		+	== 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).