[Raptor-Menu] New Raptor Design

[Siraj Razick]

HI Daf Thank you for the explanation. also not making it a book :).

On Wed, Sep 10, 2008 at 6:44 PM, Dario Freddi <drf54321 at gmail.com> wrote:

> Hey people,
> I don't want to write the book, so I'll be quick as possible :D
>
> The best way to go, in our opinion, is Plasma. And this means that Raptor
> will
> be nothing but a popup applet, interacting with a dataengine. The
> dataengine
> will mostly hold a model that the applet will use for generating the view.


There are some unfinished popup applet code in svn.. we can have this popup
in no time. and the libs will provide means of interacting with data
engines. But the question is what if some one needs to write a non
dataengine data source. some thing similar to weather engine with ions.  so
it would provide means to handle data engines and provide other simple
engines too.


>
> Let's talk about tom quickly. Me and riccardo discussed right today that
> every
> bit we need for raptor has already been implemented in KDE. So, we think
> the
> best solution for TOM would be using nepomuk based storage, by creating a
> new
> ontology. This would grant us an optimized database we can use to update
> our
> model.


> Riccardo has some other ideas about using some KRunners that I'll let him
> explain.
>
> So in the end I think we should keep the code simple, we don't need plugins
> or
> anything, that would just add a whole level of complexity without giving
> any
> real advantage. I'd aim for code simplicity that would let us maintain it
> more
> easily.


 I don't like to hard code

a. ) syscoca for apps
b. ) neupomuk for that
c .) some thing for another.

we agree on the fact that we need syscoca, nepomuk and some thing else...but
not by the means explained here :)

this idea is a good way to short circuit what's already planed . do you
think dumping krunner code into raptor search is a wonderful solution ? this
is how you build a monster .. the worst kind

 then it's much better to fock kickoff since it's already that.. raptor is a
more wider and dynamic concept.. and it has to be complex no way around
that.


>
> I personally think this kind of approach (yes, it's just a very very short
> decscription) it's the best one, though I'd like to hear some other voices
>
> Cheers
> Dario
> _______________________________________________
> Raptor mailing list
> Raptor at kde.org
> https://mail.kde.org/mailman/listinfo/raptor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/raptor/attachments/20080910/8af7a972/attachment-0001.htm