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

Siraj razick siraj at kdemail.net
Mon Aug 28 23:39:21 CEST 2006


Hi, all :-)

Lets clean up the table a bit. The requirements are very clear now..

"Raptor Menu = ALI+Kickoff+KBFX"... A Unifying Menu Concept!

1.) The Application menu should  be intelligent 
2.) It should track how the user is using the menu and also take that into 
account into it's intelligence 

Now here are some suggestion we have: 

1.) Take Keyword Entry into account in .desktop files (Thomas) when searching 
+ Other info found in .desktop files. 
2.) Use of Strigi and build a index on .desktop files and use Strigi Advace 
Grouping and Ranking facilities ::Kbfx
3.) 
>>===from a mail from Thomas===
 AI
in short: the ALI should know what you're willing to open right after you 
called it.
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
>>===========================
I think this is bit similar to Aaron's TOM :-) but with TOM the user is also 
able to controll the schedules of each task,
4.) As Aaron just noted on IRC
"The  Application  Menu should know the data but shouldn't know the source of 
the data". 
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) 

Here are the problems and conflicts we have: 

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.. 

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.   

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..

so as a team we should find a way out of this...
   
What we all agree on: 
1.) The Best KDE ever..! :-) and the Best User Experience...and loads of FUN!
2.) The menu should be Intelligent
3.) The menu should not be a linear popup.
4.) The user should be able to search for things..
5.) Make it Ant proof! 

as a final note..I know that this list has people who like to contribute 
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 
true..! and don't be afraid to step into this and comment and contribute with 
code,doc and translations..afterall this is Plasma land..even Mud pits tastes 
sweet..! and this is just a start of collecting ingredients for a Yummy Kandy 
pot.
 
 
Bye..Have fun!
-- 
Sj;
Homepage: http://www.linuxlots.com/~siraj
profile: http://www.kbfx.org/staticpages/index.php?page=20060224124718988
contact: siraj at kdemail.net



More information about the Panel-devel mailing list