You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Timothy Pearson
5159cd2beb
|
12 years ago | |
---|---|---|
.. | ||
plugins | 12 years ago | |
tests | 12 years ago | |
ui | 12 years ago | |
CMakeLists.txt | 12 years ago | |
Makefile.am | 12 years ago | |
README | 12 years ago | |
backgroundchecker.cpp | 12 years ago | |
backgroundchecker.h | 12 years ago | |
backgroundengine.cpp | 12 years ago | |
backgroundengine.h | 12 years ago | |
backgroundthread.cpp | 12 years ago | |
backgroundthread.h | 12 years ago | |
broker.cpp | 12 years ago | |
broker.h | 12 years ago | |
client.cpp | 12 years ago | |
client.h | 12 years ago | |
defaultdictionary.cpp | 12 years ago | |
defaultdictionary.h | 12 years ago | |
dictionary.h | 12 years ago | |
filter.cpp | 12 years ago | |
filter.h | 12 years ago | |
settings.cpp | 12 years ago | |
settings.h | 12 years ago | |
tdespellclient.desktop | 12 years ago | |
threadevents.h | 12 years ago |
README
This is KSpell 2 beta implementation. KSpell 2 is completely in process and is plugin based. The main class in the KSpell 2 is the KSpell::Broker. Broker is responsible for loading all the plugins and creating the actual dictionaries. Dictionaries are abstracted in the KSpell::Dictionary object which encapsulates all spell-checking functionality. You'll notice that the Broker is being created via the Broker::Ptr Broker::openBroker( KSharedConfig *config =0 ); call. The Broker is a shared object and the reason for this construct is very simple: - most application would need to have a few Broker objects (one for the dialog dictionaries, one for the background spell checking, one for the suggestion dictionaries) and because Broker loads plugins on creation it would be ineffective to have a few redundant Broker objects in one application, - each Broker maps to a configuration file. If one Broker would change in the application, all others would have to reparse and repopulate the options, which would be really inefficient. Due to the above you deal with the broker via the Broker::Ptr interface. Once you have the Broker object in your application, you can ask it for a Dictionary of some language. If such a dictionary is available you get it back as a Dictionary class and you use that class to do the actual spell checking. Broker on construction checks for available KSpell::Client's which are loaded as dynamic plugins. It's the actual KSpell::Client that gives the broker the KSpell::Dictionary. One can specify a default client and the default language for a Broker theough the settings() method and the KSpell::Settings class which it returns. Also note that you can have dictionaries for multiple languages in your application. And most importantly the interface to KSpell::Dictionary is synchronous so once you pass a word to check you don't have to wait for any signals - you get corrections right back. Sample usage of KSpell 2 looks like follows: #include <tdespell_broker.h> #include <tdespell_dictionary.h> using namespace KSpell; Broker::Ptr broker = Broker::openBroker( someKSettingsObject ); Dictionary *enDict = broker->dictionary( "en_US" ); Dictionary *deDict = broker->dictionary( "de_DE" ); void someFunc( const QString& word ) { if ( enDict->check( word ) ) { kdDebug()<<"Word \""<<word<<"\" is misspelled." <<endl; QStringList suggestion = enDict->suggest( word ); kdDebug()<<"Suggestions: "<< suggestions <<endl; } QStringList suggestions; if ( deDict->checkAndSuggest( word, suggestions ) ) { kdDebug()<<"Wort \""<<word<<"\" ist fehlbuchstabiert." <<endl; kdDebug()<<"Vorschlage: "<< suggestions <<endl; } } delete enDict; delete deDict;