dict plasma applet

[Nick Shaforostoff]

> would make most sense, obviously, if they were all in the same dataengine.
Why? Plasma-related code is only 100 lines.
On the other hand, multitran dataengine requires linking to external
libraries (their size is several megs)
Of course, this could be solved by having plugins loaded on demand,
and what if user isn't interested in Russian language (multitran is
Russian-English-Russian only)? then packagers will have to create
separate plugin packages which is equivalent to having separate
dataengines.

> perhaps have the dict engine have a Dictionaries source that lists the
> available dictionaries; then request definitions from each dictionary from the applet.
Current design is not very logical: a word is passed as a 'source'. So
Plasma::DataEngine::sources() has no sense.

I thought about the following design:
-Create separate dataengine for each type of dictionary: web,
qstardict, multitran, any other non-popular one.
-Each of these dataengines can work with several dicts (enru-bars,
enru-full, wn, gcide, ...), so Plasma::DataEngine::sources() returns
available dictionaries.
-Then, Plasma::DataEngine::serviceForSource() is used for each
dictionary (actually only for ones chosen by user in applet config
dialog) to get service, and this service is then queried for word:

 Plasma::DataEngine *a = dataEngine("dict-stardict");
 Plasma::Service *service =
twitter.serviceForSource(a->sources().first()); //this triggers
loading of the dict (btw, i'll make stardict dicts unloaded after a
minute of idleness)
 KConfigGroup op = service->operationDescription("get-word"); //other
ops may be get-word-fuzzy
 op.writeEntry("word", "test");
 Plasma::ServiceJob *job = service->startOperationCall(op);
 connect(job, SIGNAL(finished(KJob*)), this, SLOT(jobCompeted()));


Oh, and JFYI, I created a screenshot ;)
http://youonlylivetwice.info/multitran-plasma.png
Also, i got success in creating qstardict-based dataengine.