dict plasma applet

[Aaron J. Seigo]

On Sunday 09 November 2008, Nick Shaforostoff wrote:
> > would make most sense, obviously, if they were all in the same
> > dataengine.
>
> Why? Plasma-related code is only 100 lines.

so that plasmoids could deal with one engine only. engines are about 
agregation as well as uniform API.

> On the other hand, multitran dataengine requires linking to external
> libraries (their size is several megs)

looking at the screenshot, i see that this isn't about defining as much as it 
is about translation. that is indeed a separate task and imo justifies the 
separate engine.

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

it doesn't have to, nor was that what i was suggesting. sources(), in this 
case, should indeed just list the words being currently defined.

> -Create separate dataengine for each type of dictionary: web,
> qstardict, multitran, any other non-popular one.

don't design from the "dataengine implementation details" POV, but from the 
applet writer's POV.

i can see it making sense to separate word definition from word translation, 
but should the applet care if the dictionary is on the web versus local? of 
course not. that just makes both the user's life and the applet writer's life 
more difficult.

engine writing can be hard. it's work that gets done once and reused over and 
over. applet writing must be simple, however, as it's done over and over and 
only really used once per effort.

> -Each of these dataengines can work with several dicts (enru-bars,
> enru-full, wn, gcide, ...), so Plasma::DataEngine::sources() returns
> available dictionaries.

it should return all sources that actually exist; you can return sources that 
don't exist yet, but having sources() not return entries that do exist will 
cause problems. (it's used for a few different things internally)

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

Service is for write operations, not static reads. i can see how it could make 
the "match fuzzy" easier ... but that can be done using the standard methods 
of a DataEngine.

i know that finding creative uses for API such as Service is fun and rewarding, 
but it only screws over the people who will have to use it later. KISS.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20081109/d84e624a/attachment-0001.sig