On Sat, Aug 14, 2010 at 7:38 PM, Matteo Vescovi <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
