[Panel-devel] Tech Notes

[Aaron J. Seigo]

On Monday 28 August 2006 15:07, Baghira wrote:
> Am Montag, 28. August 2006 04:52 schrieb Siraj razick:
> > Thomas it's very nice..when we load data as plugins..just like I have
> > done in kbfx_plasma .if you take the current ALI and Current KBFX..
> > we are recursively looping around KService.. thing to load the
> > applications.. and the result is that we have a very slow load time for
> > the Applets..
>
> this mechanism sucks (mighty) - for a usefull app/plugin/whatever we should
> cache the data binary, stream it in, compare it to dir/file stamps and only
> handle updates (this does not break the cleartext *nix design - we'll just
> improve startup time with a binary cache ;)

KServices already come from a binary cache, and one that is already in RAM: 
ksycoca. there's probably very, very little to be won by doing this again 
ourselves. in fact, it would almost certainly be slower (since you still have 
to read the binary cache), more bug prone and take up more memory

> > I'm still wondering what you think about the idea of Separating Data from
> > Visualization (GUI) ?
>
> yes, two threads (like e.g. in amarok) will be a good idea.
> 1. because multicore is trendy
> 2. because we nothing should ever halt the desktop

this is actually what's taking me longer with the dataengines than i 
anticipated. i'm loading them in their own threads and this is bringing some 
additional complexity with it, though nothing horrid.

> I like "Raptor" then. (Rapid Application Pushing ... i'll find sth. for the
> rest ;)

not bad =)

> > we want link against solid or what
> > every..bcos we will load all that as plugins...and menu GUI want know
> > it's showing Contacts or Applications..it's just visualizing the data.
> > the Menu can also act as a DataEngine browser..so that user can just drag
> > and drop dataEngines he need to the desktop.
>
> i'm not sure if i understood that - do you wanna make the launcher the next
> konqueror?! ;)
> the inclusion of libkdehw (i assume you mean this Solid) would make sense
> for a location bar (which i would include into a separate plasmoid) or to
> handle apps on usb sticks etc. (which should/could be handled in akanodi)

akonadi doesn't have anything to do with usb sticks, and solid will have a 
dataengine

> > We should talk to Aaron and also Vandenoever ( Strigi Author : who is
> > very helpfull ..also for ideas.as they are working on Tanor and Strigi
> > already has a Ranking systems..I will ask him what his ideas on this 
> > matter..and this is a major part , I think we should decide before
> > coding... to test I will try to write a Strigi plugin to kbfx_plasma in
> > svn and try to index the application .desktops files..and do a search and
> > see how intelligent the results. are...what do you think thomas?
>
> I'm not sure if a Desktop search engine fits our needs. Usually they rank
> by count and in few cases by position.
> We should not rely on all the data in the desktop files. it includes i18n
> strings and descriptions that aren't as usefull as striking keywords.
> Also i wanna include the users profile (that is usage by app and category)
> we should talk to the strigi/tenor guys and ask if they have anything like
> this, but i really doubt (a general desktop search has to provide other
> abilities while an app laucher should not be optimized to find documents)

strigi can group data sets, e.g. "applications", and search just on those. 
usage statistics should also probably be added into the search database once 
it is that far along in maturity so that it can be used (both added to and 
queried for) by multiple apps...

of course, there's also the use case where the user does want to "search 
everything" including documents.

-- 
Aaron J. Seigo
Undulate Your Wantonness
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20060828/4c782f53/attachment.pgp