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 <[EMAIL PROTECTED]>: > 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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
