[Panel-devel] Raptor(){Menu Ideas {Data {AI{Search}}}}

[Aaron J. Seigo]

On Monday 28 August 2006 15:39, Siraj razick wrote:
> therefore i'd analyze the users app launching behaviour (i.e. session just
> started, we need a konsole, kmail, amarok and konqueror, or: 12:30 launch
> break, we wanna play ksudoku) and have a ranking system on top of a
> (simple) bayes filter

timelining based context ... this is something i'm interested in helping R&D 
once i'm a bit more clear from immediate nuts and bolts stuff.

> 5.) 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
> againourselves. in fact, it would almost certainly be slower (since you
> still haveto read the binary cache), more bug prone and take up more memory
> .. Aaron<-
>  ->Richard
> This is true but IIRC only the system level things are cached. It
> might be worth considering if we should be caching user specific stuff
> too. That said, this is of course an optimisation and can be looked at
> later after profiling.( From Richard Moore)

right now the user specific stuff is cached during runtime, but read in from a 
summary stored in a text config a load time. currently the amount of data 
stored in this fashion is extemely small and therefore not significant to 
startup overhead, and from that point forward is kept resident in memory. the 
only annoyance right now is that we write it out to disk fairly often IIRC 
(after each alteration?). not great.

the RecentlyLaunchedApps class needs to be replaced. in fact, i'm not sure 
this even belongs in plasma as it needs to be accessible from other points, 
such as the run dialog. right now the run dialog is part of the desktop, but 
that's not acceptable if we combine the desktop with the panels. IMHO, the 
run dialog (which needs revisiting at some point in kde4's life; not a hot 
point for 4.0 perhaps but would make a nice 4.1 improvement) should be 
isolated into it's own long-running service and perhaps combined with a 
simplified task listing. this would allow nice isolation (and process 
prioritization) of these two critical desktop services.

> Thomas: dose not like Stigi: :-) as he thinks of it as a desktop search
> engine..which is too much for a Menu..But as a personal note  I do not
> think this as a big problem.as if we are using plugins as Thomas agrees on.
> we can switch off what we don't like. like in Kate or kopete..

if strigi is only to be used with the ALI then yes, it doesn't make sense.
if strigi becomes more widely used on the desktop then it becomes a shared 
resource. the value of strigi and similar systems is derived directly from 
the number and variety of data sources it draws upon with the filesystem 
being simply one of those sources.

> Kickoff: the Data is had coded into the menu ..very similar to the current
> Kmenu..actually from what I heard from Coolo(Kulow) ..it's a BIG patch to
> kicker; but there is no clear separation of data and GUI and links with
> Beagle ( I think).other than that; we have good things we can use in Raptor
> from  Kickoff.

agreed.

> KBFX: Data source should be Separate from GUI and have a Generic search
> engine which allows for applications as well as files ( emails ,,
> notes..).. and also have plugin specific search methods. and let the user
> turn off what he dosen't want. which allows for hiding the data source from
> the menu..

a plugin based search system essentially removes the 
to-strigi-or-not-to-strigi as well as the "but we want beagle, love novell" 
issues. i like that =)

> but just wondering into KDE4 and looking for a place to start. surely
> we wellcome all to Join the "Plasma Raptor" and make the Raptor vision come

the run dialog separation is another fairly straightforward task that would be 
a welcome entry point...

-- 
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/20060829/58d64daa/attachment.pgp