Re: RFS: presage

[Paul Wise <pabs@debian.org>]

On Sat, Aug 14, 2010 at 7:38 PM, Matteo Vescovi
<matteo.vescovi@yahoo.co.uk> wrote:
> Paul Wise wrote:
>> pypresage causes a segfault in python when I turn on learn mode and
>> type some things, could you add a -dbg package please? Not sure but
>> the segfault could be related to this message:
>>
>> [DatabaseConnector] Error executing SQL: 'INSERT INTO _1_gram
>> VALUES('dfsdfsd', 1);' on database:
>> '/usr/share/presage/database_en.db' : attempt to write a readonly
>> database
>> terminate called after throwing an instance of
>> 'SqliteDatabaseConnector::SqliteDatabaseConnectorException'
>>
>
> Correct, the exception is thrown because the language model database is not
> writable. The adaptive learning mode requires write access to the language
> model.

I think perhaps the demo app should catch the exception and pop-up a
warning instead of crashing when it cannot write to the database.

>> That message indicates that the database is in the wrong directory
>> since it needs to be modified. I'm now thinking that it belongs in
>> ~/.presage or similar rather than /var or /usr/share. Probably each
>> user is going to want to have a different predictive text entry model
>> anyway.
>>
>
> Yes, I agree that users of the pyprompter and gprompter might want to use
> their own language models. These users should configure the application to
> point to a user-specified language model. Currently, the only way to do so
> is to edit presage.xml.
>
> I am considering adding a script that will set things up when pyprompter and
> gprompter are installed:
> - copy language model database to ~/.presage/
> - copy configuration file from /etc/presage.xml to ~/.presage.xml
> - modify ~/.presage.xml to point to user writable language model in
> ~/.presage/
>
> The language models and configuration are installed in /usr/share and /etc
> by the libpresage-data package, which is a dependency of libpresage1 (which
> all other packages depend on). I think this makes sense, as libpresage needs
> this data to work and generate predictions. Adaptive learning cannot be
> turned on while using the data from /usr/share, but that's ok because users
> (or other applications using the presage library) would have to configure it
> to their needs anyway and wouldn't just use the default config.
>
> Thoughts?

Hmmm, I think the library should automatically clone the read-only db
into the per-user db when the latter is not available. I don't know
enough about the configuration, but probably the library should load
defaults from /usr/share/presage/conf.d/*.xml (for
packagers/derivatives/etc), /etc/presage.d/*.xml (for sysadmins). Then
if the user/UI/lib needs to modify the configuration, it writes only
the changed parameters to ~/.presage.xml (or similar, see XDG basedir
spec).

>> On systems without a keyboard, just a touchscreen, you probably don't
>> need to display F1 F2 F3 F4 ... etc. Not sure if there is a way to
>> detect that. On keyboards without Fn keys you might switch to 1 2 3 4
>> ... instead, also not sure if that is detectable.
>>
>
> Well, it is possible to disable displaying of the F1, F2, F3,... keys in
> pyprompter by unchecking the "Presage -> Function keys" menu checkbox (or
> using the CTRL + F shortcut).

Ok, so you just need to figure out a way to detect if the keyboard has
FN keys or if you are on a touchscreen.

>> I played around in pyprompter for a while but I wasn't really
>> satisfied, just typing seemed faster. I guess on something like a
>> touchscreen it might be better. Or does it get better the more you
>> train it? Would a larger database of gutenberg texts make it work
>> better?
>>
>
> It does get better the more you train it. Training a language model with a
> representative corpus of text also improves predictive performance.
>
> However, it is important to keep in mind that the aim of a predictive text
> entry system is to improve ease and speed of textual input when:
> * the device is equipped with a limited text entry system, such as devices
> lacking a standard keyboard, i.e. portable devices, PDAs and mobile phones
> * the user has physical or linguistic disabilities which might impair their
> speed, accuracy, or altogether prevent their access to electronic text
> creation
>
> Matching (let alone improving upon) the text entry rate of a user with good
> typing skills using a full size keyboard is probably going to be very hard
> to achieve. Quoting from "Tina Mangunson and Sheri Hunnicutt. Measuring the
> effectiveness of word prediction: The advantage of long-term use":
>   "The usage of word prediction does, however, impose a high degree of
> perceptual and cognitive load since it requires the user to shift attention
> from the text in progress to the prediction suggestions. Especially for
> persons with learning disabilities but with good keyboard skills it may be
> distracting to have to interrupt the flow. Sometimes the cognitive load
> costs more in terms of text generation rate (Fazly 2002)."

The main issue I have with the predictive text on e17 is that the
sequence of characters I actually typed is hidden away instead of
being the first option. Preventing me from typing what I want isn't a
very user-friendly thing to do.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise