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



> 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



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