Is there some way to turn the predictive dictionary off?
Carsten Haitzler (The Rasterman)
raster at openmoko.org
Wed Jul 30 03:26:18 CEST 2008
On Wed, 30 Jul 2008 02:09:03 +0100 Al Johnson <openmoko at mazikeen.demon.co.uk>
> On Tuesday 29 July 2008, Carsten Haitzler wrote:
> > On Fri, 25 Jul 2008 10:12:08 +0100 Al Johnson
> > <openmoko at mazikeen.demon.co.uk> babbled:
> > ok. now in illume svn there is code to confiugre what keyboard you want
> > (illume's, none at all (which means if qpe provides one that will be used),
> > or some other one. other keyboards must install a .desktop file with a
> > category of "Keyboard" in the categories list).
> > anyway... in addition there is code to talk to hal and query for kbd
> > devices and listen to hal device adds/dels, and i have a primitive glob
> > matcher that allows a list of globs (currently hard-coded - probably will
> > move to a file) that are globs for identifying "existing keyboards to
> > ignore" when figuring out of a "real keyboard" has been plugged in and thus
> > needs the virtual kbd to be disabled. if a real kbd is plugged in i added
> > disable code to the
> > virtual keyboard handler... that SHOULD work. completely untested. it
> > compiles.. it runs and doesn't segv... i have no "real" keyboatd to play
> > with right now.
> Sounds good. I'll have to get dual boot going before testing. Will this get
> into a nightly build or will I need to build it myself?
right now, u'll need to build yourself. the nightly builds will still have
qtopia's keyboard running and basically will clash will illume. there is an
environment var u can use to turn off qtopia's kbd - forgot what it is tho...
u'll have to set it in qpe's startup script.
also the config is available in a gui but that gui config will go soon enough.
there is a dbus api too - but having to run complex dbus commands by hand is
Carsten Haitzler (The Rasterman) <raster at openmoko.org>
More information about the community