dict plasma applet

[Aaron J. Seigo]

On Sunday 09 November 2008, Nick Shaforostoff wrote:
> > don't design from the "dataengine implementation details" POV,
> > but from the applet writer's POV.
>
> and what's the application of this rule in our case?
> what's your design suggestion?
> i can see no other ways of advanced interaction with dataengine aside
> from Plasma::Service

nothing you've described thus far is advanced interaction.

> > 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.
>
> in my design the applet doesn't care (it's just names - web, stardict,
> multitran, ...; those dataengines will have same interface -- much
> like plugins of qstardict, see [1]), but user may want to. for example
> we may have gcide web dictionary that fetches info from the internet,
> and gcide (=local) stardict dictionary. obviously user will want to
> disable gcide web dicitionary, to avoid having duplicate results and
> wasting bandwidth.

this is doable with a single engine or multiple engines, and you can use a 
Service to do the engine configuration (if any is actually required); but the 
question you need to answer is: "Am I creating a web dictionary engine, a 
stardict engine, etc. or am I creating an engine that returns the meaning of 
words?"

> >> -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
>
> i'm afraid i wasn't clear enough.

no, you were clear. it's just not how DataEngines are meant to be used. 
deviating from that will remove the simplicity and predictability of them for 
applet writers.

when you get data from a DataEngine, it should appear as source. sources() 
must return all existing sources.

Services are there to allow write access (mutators) to whatever the source 
represents.

so it would be not just odd, but by the design definition broken, to use a 
Service to read data from a DataEngine.

-- 
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/59245e7f/attachment.sig