> No problem! Mon francais, c'est plus mauvaise ;-) :D cool !
> 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. It's just a line in the config file but a graphic way of change have to be done. It's more easy to find the group you need with alphabetic order but when the group come from a list of letter in the frequency order, i think that with a bit of practise, you can gain some time. Especially in the case of that a disabled people just wink, and another person count the number of wink and just click on the right group. I'm sure that it can be very fast :) > 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. I have to check how you handle the dict but like i said the dict have more than 300000 words with their google frequency. My way of using the dict adapted in the SQLite base can probably be optimize but for test with gok, why not. > 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... The re-calculation of the combo for more than 300000 words dynamically can be a hard work even with a good algo :) We not have all a enterprise 10000 at home ;) > 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. For example :) A lot of ideas again :) Some virtual keyboard use group of action with draw. It can be adapt to gok. Like in video games where usual sentences are pre-recorded "Attack this" "Protect me" etc. > This is already possible. You can define new GOK keyboards, and substitute one for the 'Compose' keyboard. I didn't find documentation on the xml format used in this file. Is there something on the doc or it's include in the source code ? >> Is it possible to adapt my databases ? > I am pretty sure it is. The file will be in the download part of https://gna.org/projects/pylisiere , normally this week. > 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. You didn't see my code ! It's not very clean :) But like all in python, it's easy to change. Have a nice weekend ! -- Freedom - Share - Respect _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
