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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]