dict plasma applet

[Thomas Georgiou]

I haven't had time to work on dict for a while, but i should have some
time later this week to review the design.  The design right now is as
a dict protocol engine (RFC xxxx).  Ideally, there should be a
dictionary engine that is independent of the underlying source (now
that i look at it, star dict looks very nice) that applets can just
use.  Shouldn't dictionary services be integrated into Sonnet though?
Then there would just be a sonnet dataengine if one is needed at all.
In any case, changing the design of the engine to be able to use
something other than dict entails a complete rewrite, which would
probably be useful since it has a lot of cruft from pre-4.0 plasma.

Thomas Georgiou

2008/11/9 Aaron J. Seigo <aseigo at kde.org>:
> 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
>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>