Re: [g-a-devel] GOK and a different way of show keyboard

[Bill Haneman <Bill Haneman Sun COM>]

rangzen wrote:
> Thanks for yours positive answers !
>
> Let's start a long email. Once again and a last time :) forgive my english.

No problem!  Mon francais, c'est plus mauvaise ;-)

> ...of code time to time ... Pylisiere is just a proof of concept but i think
> it can work. Now, with what i saw and what i thinking understand on the
> need of disabled people, i think that the best way for my ideas, is the
> integration of my "work" like a way of input in gok.
...
> My main goal is to gain time to permit a dialog with more than 8 words per
> minute if you have only a binary signal to communicate. 

I agree that this is a great goal, and I think it should be feasible.

> The choice in group of letters is free cause i didn't find "the better way".
> [abcdefgh][ijklmnopqr] or [abc][def][ghi][jkl][mno] or [et][ianm][svrw] or
> etc. I think that the best is to purpose the choice to user.

Yes, but one question is, how does the user choose the groups?  I 
suggest that we could start out with the familiar "telephone" letter 
groupings which are familiar to many people, but of course any 
arrangement would be possible.

As you point out, the hard part is the dictionary and the search 
algorithm.  I think these could stay in Python, since Python and C are 
not difficult to integrate.  If the existing word-prediction interfaces 
in GOK are not sufficient, we can extend them to handle this case.

> Example :
> map = [abc][def][ghi]
> combo of "cei" is "123"
> combo of "eehhh" is "22333"
> In the interface, the user choose the first group of letter and 3 times
> the second, the combo is 1222. It's a lot faster to search the words wich
> match 1222 in their combo than search all the word wich can match with
> fisrt letter in this first group of letters and second, third and fourth
> letters in the second group of letters.
> A bad point, you need to compute combo for each word each time you change
> the map of the group of letter (normally, not every ten minutes ...).

That shouldn't be too much of a problem, if the map is not changing 
dynamically.  But it may be that some even more efficient algorithm 
would change the map according to the scores of the letter-groups 
already chosen...

> One of my idea to accelerate more, is to have a way to define new word
> unuse like shorcut.
> Example : the combo 33333 is unuse, you can bind 33333 to "I'm hungry !"

That's a nice idea; I wonder how to expose this to the user effectively?
Perhaps it makes more sense, because with single-switches, selection 
already requires scanning through the set of groups (i.e. 33333 requires 
5 separate scans through the list), to offer a special GOK keyboard 
which branches to a list of often-used phrases.  So a special key on the 
keyboard would 'branch' to a list of common phrases, or a keyboard of 
'topics' from which a common phrase could be chosen.  This might reduce 
the number of selection steps to '3' instead of '5', for a common phrase.

> Do you think that it's easy to change the part under "compose" in gok ?

This is already possible.  You can define new GOK keyboards, and 
substitute one for the 'Compose' keyboard.

> Is it possible to adapt my databases ?

I am pretty sure it is.

> Is it a "big" adaptation ?

Possibly not.

> I will look in the source code but i'm not very happy to leave python :)

I think it makes the most sense to look at your Python interfaces, and 
the GOK interfaces, and not worry about the implementation details, so 
that we can find the best place to integrate your interfaces and ours. 
I would hope that only a little C code would be required, and most of 
your code could stay in Python.

Thanks, we look forward to working with you!

- Bill

> I can make xml or other but come back to C ... I don't know ...
>
> Thanks !


--
------
Bill Haneman
Gnome Accessibility Project
Sun Microsystems Ireland