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
On Sunday 09 November 2008, Aaron J. Seigo wrote:
> On Sunday 09 November 2008, Mark Kretschmann wrote:
> > since bumping libplasma in Amarok recently we have been experiencing
> > problems with our containment layout. The problem becomes visible if
> > you zoom out of the containment: Instead of a
> 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
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.vidsolbach.de/r/265/#review259
---
Ship it!
this is good imo. we can even force updates this way by
On Sunday 09 November 2008, Mark Kretschmann wrote:
> since bumping libplasma in Amarok recently we have been experiencing
> problems with our containment layout. The problem becomes visible if
> you zoom out of the containment: Instead of a grid of 2x2, Amarok now
> shows all containments in one r
Hello everyone,
I just stumbled across this on gizmodo and wanted to share it with you:
http://gizmodo.com/5080163/what-photoshop-would-look-like-in-real-life
The idea is really amazing. I think occasionally reflecting upon the
relation of real world tools and the metaphors we use in user
interfa
> 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
Hey Plasmoids,
since bumping libplasma in Amarok recently we have been experiencing
problems with our containment layout. The problem becomes visible if
you zoom out of the containment: Instead of a grid of 2x2, Amarok now
shows all containments in one row, which hides some of the
containments due
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.vidsolbach.de/r/265/
---
Review request for Plasma.
Summary
---
This micro patch make expire th
15 matches
Mail list logo
