On Wednesday 12 November 2008, Nick Shaforostoff wrote:
> > for instance, keep the dict applet in kde's svn and keep the engine with
> > qstartdict. there's no reason for an applet dedicated to stardict when we
> > have another dictionary widget there.
>
> I improved applet part: it got configurati
> for instance, keep the dict applet in kde's svn and keep the engine with
> qstartdict. there's no reason for an applet dedicated to stardict when we
> have another dictionary widget there.
I improved applet part: it got configuration (enable/disable
dictionaries, reorder them).
The qstardict en
On Tuesday 11 November 2008, Thomas Georgiou wrote:
> Technically, dict engine is an interface for the dict protocol, but it
> still needs work which i don't have time for right now.
what work does it need?
(and yes, the dict applet should remain as the single visualization for all
these engines
Technically, dict engine is an interface for the dict protocol, but it
still needs work which i don't have time for right now.
Thomas Georgiou
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
On Tuesday 11 November 2008, Nick Shaforostoff wrote:
> It uses QTextBrowser instead of QWebView (saves ~5 megs of ram) allows
any reason you aren't using the Plasma widget classes for this?
i also assume this means the dict plasmoid and engine in kde's svn are
abandonware at this point?
it's g
Please welcome qstardict plasmoid!
http://qstardict.ylsoftware.com/svn.php
http://qstardict.svn.sourceforge.net/viewvc/qstardict/trunk/
It uses QTextBrowser instead of QWebView (saves ~5 megs of ram) allows
specifying order of dictionaries, loads plugins only when a definition
requested by user a
On Monday 10 November 2008, Nick Shaforostoff wrote:
> So I'll just import my dict plasmoid to its repository
> (qstardict.sf.net) renaming it from dict to qstardict and release it
> separately as part of qstardict.
looking at qstardict it seems to be a full application with plugins for
stardict
2008/11/10 Nick Shaforostoff <[EMAIL PROTECTED]>:
> What I will do now is just turn dict dataengine into wrapper around
> qstardict plugins:
> in addition to web (konqueror web-shortcuts-like), stardict and swac
> (sounds fetching) plugins i'll create multitran and rpc plugins (the
> last one is ju
On Sunday 09 November 2008, Zack Rusin wrote:
> On Sunday 09 November 2008 19:26:06 Aaron J. Seigo wrote:
> > On Sunday 09 November 2008, Thomas Georgiou wrote:
> > > dictionary engine that is independent of the underlying source (now
> > > that i look at it, star dict looks very nice) that applets
On Sunday 09 November 2008 19:26:06 Aaron J. Seigo wrote:
> On Sunday 09 November 2008, Thomas Georgiou wrote:
> > 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.
>
> right.
>
> > Shouldn't dictiona
> 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?"
thanks, you've convinced me.
What I will do now is just turn dict dataengine into wrapper around
qstardict plugins:
in addition t
On Sunday 09 November 2008, Thomas Georgiou wrote:
> 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.
right.
> Shouldn't dictionary services be integrated into Sonnet though?
sonnet is about spell che
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 ). Ideally, there should be a
dictionary engine that is independent of the underlying source (now
that i look at it, star di
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 w
> 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
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
> would make most sense, obviously, if they were all in the same dataengine.
Why? Plasma-related code is only 100 lines.
On the other hand, multitran dataengine requires linking to external
libraries (their size is several megs)
Of course, this could be solved by having plugins loaded on demand,
an
On Saturday 08 November 2008, Nick Shaforostoff wrote:
> i've done first steps in writing a dataengine for multitran-data
> (multitran.sf.net, multitran.ru), and also plan to write
> qstardict-based dataengine.
would make most sense, obviously, if they were all in the same dataengine.
> so i will
2008/11/8 Thomas Georgiou <[EMAIL PROTECTED]>:
> Well, initially we used a qgraphicstextedit with html formatting to
> make it look nicer, but we could not have scrolling with that, so when
> 4.1 came along we switched to qwebview (to get scrolling support).
> Then we switched dictionaries to wordn
Well, initially we used a qgraphicstextedit with html formatting to
make it look nicer, but we could not have scrolling with that, so when
4.1 came along we switched to qwebview (to get scrolling support).
Then we switched dictionaries to wordnet, and the parsing to html code
has not been rewritten
20 matches
Mail list logo
