> 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
> 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.
>> -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. Suppose there are three dictionaries
in /usr/share/stardict/dic: enru-bars, gcide, wordnet. So querying
dataEngine("dict-stardict")->sources() will return QStringList
containing names of those three dicts: ("enru-bars", "gcide",
"wordnet"). The list will change only when contents of
/usr/share/stardict/dic changes.
[1]
http://qstardict.svn.sourceforge.net/viewvc/qstardict/trunk/qstardict/dictplugin.h?view=markup
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
