GP2X Text Entry Idea + Prototype App

[gfxpulse]

Some thoughts on the topic:
(feel free to take them worth a grain of salt)

You may wish to check out Dasher (http://www.inference.phy.cam.ac.uk/dasher/)
It looks rather silly, and is a bit awkward at first, but I think might be interesting as it only requires the joypad. It can be very fast (The webpage claims upto 39wpm), at least faster than I can type on a cellphone. The only downside to dasher is that it would probably require the full screen, so it would need to be toggled on and off. Dasher is under the GPL license (and has pda ports, so you could see how they manage to toggle it).

Also, IBM has quite a bit of research published about different text input methods. I do not have a link, but can find one if anyone is interested.

 

[gfxpulse]

'Multi-tap' systems require waiting for timeout when adjacent letters are on the same key.

Ah, yes, but you are forgetting that you can release the D-Pad and press it again to go back to the same bank, so no delay.

Your example 'ON'

1) Press right, tap three times for 'o'
2) release pad, press right again, tap 2 times for 'n'

​

Unfortunately, this wouldnt work for letters j,k, or l? Or does the center bank require pressing in the button? It is probably a moot point, because j,k, and l are fairly uncommon letters to be next to each other in words

 

[noir.pl]

You may wish to check out Dasher (http://www.inference.phy.cam.ac.uk/dasher/)
It looks rather silly, and is a bit awkward at first, but I think might be interesting as it only requires the joypad. It can be very fast (The webpage claims upto 39wpm), at least faster than I can type on a cellphone.

I know dasher as it is included in Gnome (Applications->Accessibility->Dasher).
It is fast but it requires *insane* amount of focus, and rather large screen.

Also, IBM has quite a bit of research published about different text input methods. I do not have a link, but can find one if anyone is interested.

Of course we are interested

 

[gfxpulse]

I know dasher as it is included in Gnome (Applications->Accessibility->Dasher).
It is fast but it requires *insane* amount of focus, and rather large screen.

Anyone have a pda to let us know how dasher works on a small screen?

And, its a gaming system, of course you are focused. (lol).

I agree that dasher may not be perfect, but, i think it is better than mobile phone-esque entry.. and the speed is variable...

Will find those links on the IBM stuff later on.

If anyone else comes across any other papers/programs, please post them.

 

[woogal]

When I was looking for a text input system I came across a paper on using EdgeWrite with joysticks and it was exactly what I was looking for - easy to use without having to hunt around on the screen for letters, and possible to use without taking up any screen space at all. My GP32 test became EdgePad.

 

[pea]

Unfortunately, this wouldnt work for letters j,k, or l? Or does the center bank require pressing in the button? It is probably a moot point, because j,k, and l are fairly uncommon letters to be next to each other in words

Hehe, but yes, for these letters just press the D-Pad left and then release again The opposite then..
1) Press 'A' twice for J
2) Click D-Pad left and release again
3) Press 'A' three times for L
etc

EDIT: Dasher is INSANE! By the end of a short message you would be a hyped up nervous wreck, let alone by the end of anything of decent length!

Edge write is very cool and fast, but it takes time to learn the new system.

I think TXT grid coupled with T9 is the best trade-off in terms of speed, ease of use and SANITY!

I like Your idea so much, that from now on I will focus entirely on text prediction / text completion.

Why thank you I have put a lot of thought into it already in the past, which is why I have the idea all figured out so well. Its actuall the next step I am taking in GPDesktop for the GP32 (in c). I will send you the source when it is complete I would love to add some form of prediction too. Out of curiousity, how much memory would a decent dictionary (for predictive text) take up in memory?

 

[noir.pl]

Out of curiousity, how much memory would a decent dictionary (for predictive text) take up in memory?

My first prototype in C required 64kB for dictionary of 2000 words. But that prototype was complicated as hell so I throw it away. Currently I'm working on dictionary stored in BER-like format that will require about 32kB for 2000 words. It's worth to mention that this format is designed to allow direct usage from disk so even very large dictionaries (size counted in MB) will require only few kilobytes of RAM.

 

[noir.pl]

Good news

First version of my "dict" library is available here:
http://rapidshare.de/files/7048757/dict-0.2.tar.gz.html

Features:
* T9 like functionality,
* BSD licence (most liberal licence possible),
* small footprint,
* no dependencies,
* built-in dictionary of 2000 most common english words,
* extremally easy API (but no documentation yet, only example).

It's still very early version (0.2) so I have implemented only limited
functionality - no text completion yet, only reverse hashing.

Ok, here's an example:

#include "dict.h"
#include <stdio.h>

void dump(char* ptr, int maxlen)
{
    int i;
    for (i=0; i<maxlen; i++)
        printf("%c", *ptr++);
    printf("\n");
}

int main()
{
    char buff[40];
    int matched_cnt;

    // should print "cardcarecasebase"
    matched_cnt = dict_decode("0051", 4, buff, 10);
    dump(buff, 4*matched_cnt);

    // should print "excellent"
    matched_cnt = dict_decode("170133146", 9, buff, 4);
    dump(buff, 9*matched_cnt);

    // should print ""
    matched_cnt = dict_decode("0000", 4, buff, 10);
    dump(buff, 4*matched_cnt);

    return 0;
}

And the Makefile:

CFLAGS= -g

all: dict_image.o dict.o example.o
	gcc *.o -o example

clean:
	rm -f *.o example

The footprint is better that I thought: only 25kB per 2000 words.
New version (with documentation this time) should be available in few days.


Here's ultra compact API description:

int dict_decode(char* addr, int len, char* output, int n);
returns: number of matched words
addr: encoded text ('abc'->'0', 'def'->'1', 'ghi'->'2', 'jkl'->3, 'mno'->'4', 'pqrs'->'5', 'tuv'->'6', 'wxyz'->'7')
len: length of addr
output: pointer to output buffer (buffer size must be >= len*n)
n: maximum number of returned matched words
matched words will be written into output buffer


Ok, that's all for now.

 

[K0K0NUT_h3lmut]

I haven't read through all of this thread, but does this mean that it may be eventually possible to code on the go with my GP2X? Similar to how people can code with TI-89 calculators...

 

[dabogsta]

I use Dasher all the time. When i just want to input a webpage and dont want to get up(wireless keyboard/mouse), Dasher works great. After a while you get used to the setup and can input text pretty quickly. It seems like it would work without too much of a hassle since it is already linux, but it would take up the whole screen. Maybe a button press could toggle it on and off or something...

 

[gp2brew]

Here is a mockup in flash:
http://www.pea.co.nz/gp32/gpd_input.php

Please note that it is designed for the gp32, and hence only makes use of A and B (not X,Y or the D-Pad button).

​

I wasn't sure about this concept initially and just tried your flash demo. It's really pretty darn good, I can imagine how easy it would be to use on the GP32.

If I have time I might do a simple mockup in Fenix, I've been dying for some kind of chatboard support there for testing some ideas, and this would work just fine

Good work!

Cheers,

DCC

 

[noir.pl]

I haven't read through all of this thread, but does this mean that it may be eventually possible to code on the go with my GP2X? Similar to how people can code with TI-89 calculators...

Well... TI89 has few more keys so it's somehow better suited for this kind of job. But I think that it will be possible also on gp2x.

I use Dasher all the time. When i just want to input a webpage and dont want to get up(wireless keyboard/mouse), Dasher works great.

Maybe it's just me, but I find dasher rather hard for this task. Few minutes ago I tried to enter "http://www.gp32x.de"... And failed. What dasher implementation are you using? Maybe only Gnome version (which I use) sucks?


Anyway... My 'dict' lib is progressing slowly but steadily. You can expect following features in the next version (0.4):
* returned word list sorted by word weight (weights reflects usage probability),
* slightly changed output format (every word preceded by length),
* dictionary of 45000 words,
* tool for converting myspell dictionaries into dict-format,
* documentation ,
* configurable key mappings (it will be possible to do n-key versions of t9),
* better error handling.

Text completion planned for version 0.6.

 

[jedthehumanoid]

Ok, i'm clueless here so bear with me for a while. :rolleyes:
I don't know either if this already has been done/thought of, or if its possible.

But could it be possible to have some kind of input-"plugin"-system?
Where you can use your favourite flavour of text input like the ones discussed here, or connect chatboard/et.c ( IF such devices become avaliable).
Every application/game that support it just ask for keyboard input, and gets it regardless of method used.

[speculations]
Could something like this be impemented through SDL's inputevent system?
A called inputroutine could send the event "SDLK_F" for example if F is pressed or emulated otherwise.
[/speculations]
Am i completely out in the woods? :unsure:

This would futureproof applications, everyone will be able to select their own preffered method (T9, predictive input, dasher, etc...), and if some input method is patented (as discussed erlier) developer wouldn't be held responsible if say someone would like to hack a plugin and use that method in an application -_-