Re: RFS: presage

[Matteo Vescovi <matteo.vescovi@yahoo.co.uk>]

Hi Paul,

Thanks again for reviewing this package.

Paul Wise wrote:
> > http://mentors.debian.net/debian/pool/main/p/presage/presage_0.8.4-2.dsc
> >     
>
> Have you seen and used the abi-compliance-checker package? It would be
> good if you could use that upstream to ensure that you do not break
> the ABI.
>   

No, I didn't know about ABI compliance checker. I'll add it to my TODO 
list and will look into it, time permitting.

> Copyright info for your stuff should be 2004-2010.
>   

Done.

> Some copyright info for these files is missing:
>
> apps/dbus/presage_dbus_service*
> apps/gtk/gpresagemate/gpresagemate.cpp
> apps/python/presagemate/presagemate.py
> apps/python/pypresagemate*
>   

Added entries for those files above.

> Please add DEP-3 headers to this patch and don't forget to commit it upstream:
>
> debian/patches/fix-hyphen-used-as-minus-sign-in-text2ngram-man-page.patch
> http://dep.debian.net/deps/dep3/
>   

Done.

> debian policy 3.9.1 is out.
>   

Upgraded to latest policy.

> 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.

> 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?

> In pyprompter, when I switch to another application, the prompt menu
> stays over the top of that menu.
>   

Yes, that's a bit annoying. Upstream is aware of this issue (it seems to 
be a problem with the wxWidgets / wxPython toolkits).

> 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).

> 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)."

> Have you compared presage with other predictive text entry systems
> such as the ones on commercial mobile phones or the one in the
> keyboard from e17 in Debian or the one from QtMoko?  

No. It would be very interesting to have a comparison done.


The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/presage
- Source repository: deb-src http://mentors.debian.net/debian unstable 
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/p/presage/presage_0.8.4-3.dsc


Cheers,
- Matteo