< Projects
Revision as of 20:31, 19 April 2007 by Tampakrap (Talk | contribs) (Raptor design spec...)

Jump to: navigation, search


Current Development

The Demonstration applet for Raptor can be found in KDE SVN( . You can run this applet under KDE3 to see few of the features we want to have on Raptor.

Raptor design spec...

The main goal of Raptor is to deliver a unique menu for KDE, that is easy to use yet also eye-candy and with customisable look and feel

The Main goal of Raptor Design (technically) is to abstract the source of the data. The Data Source is implemented as DataSource Class. The DataSource Class itself is implemented directly in LibPlasma.

The loading of the Data Source is handled by the Data Engine, which is found as DataEngine Class also in Libplasma... which knows how to handle the Source. Thus it is possible to create and hook in other Plugins as wished, without changing the main Code of Raptor.

Raptor will load the Plasma DataEngines through an Interface to gain access to the DataSources. By specifying these interface for Raptor, and a plugin handler, others can write their own plugins with datasources and -engines and add it in Raptors configuration. Raptor then tells the plugins to deliver data via the interface (updateData or sthg) and the plugin sends these data in the form that it fits through the interface into it.

RaptorMenu Areas

There will be 5 basic areas of the Menu: The header, The footer, The categories pane, The elements pane and a shortstart bar. Each of them can be configurated seperately: will they be displayed (available for header, footer, shortstart), where, how many rows it contains (available for shortstart, elements) and which of the possible parts and plugins are loaded (does the header display a user logo or not, are there further plugins in the categories bar?, which buttons are displayed in the footer, lock, logout, standby, restart?)

RaptorMenu Behaviour

Since Raptor is a Plasmoid, resizing will be handled automatically.

The first category/plugin that is opened at the press of the startmenu can be either the one with thomas' AI logic or any of the loaded categories. The proposed AI Logic of Thomas can be found at the end of the spec, as it is kind of a subproject...

Search will be done via Strigi, Tenor (even beagle is possible with a plugin) or any other search engine that is configured. The search results will be kept in the category "search", even if another category/plugin is selected, until a new search is started.

Additionally to the scroll solution as it is now, we will provide other options, a kind of vertical adjusting wheel at the right side of the elements pane.

Instead of having some kind of context menu popping up, the right-clicked element / category could just turn around and present the options on the back of the graphic of this Element.

Category handling can optionally be done via tagging instead of building a tree. We tag the elements with one to n tags, and it appears as soon as the tag is called. This concept is further refined by a rating on the assignment between tag and element, so that OpenOffice.Org Writer can be rated 5 on the tag write, but 4 on the tag OpenOffice.Org. We will then use this rating for sorting the elements. Depending how the labels are set, a task oriented start menu can be realized easily. We should predeliver a set of common label schemes.

Raptor Searching

Until Tenor is ready, Raptor will depend on the Strigi Search Plugin to provide searching capabilities. As Strigi and Tenor will evolve and develop further, the searching capabilities of Raptor will also evolve and improve. The search engine will provide Raptor with a DataEngine, and each search element abstracts a DataSource, so that the results can be remote or local, inside tar files or in locally mounted remote shares, such as NFS or samba. The Source of the search results does not matter for Raptor.

In Short

1.) The Menu will have Skin support. The user / artists can make raster (png like) and vector (svg like) themes for Raptor.

2.) The user will be able to blend / change the color of the skin.

3.) The user can also change the layout of the menu elements.

4.) The menu can have fancy effects like Fire and Rain :-)

5.) Configuration should be done in the Plasma-manner....

Coding Guide lines Please read kdebase/workspace/plasma/HACKING for coding guidelines. and Try to follow this so that the plasma code is very clear and clean.

Raptor AI Engine

Raptor was the most intelligent Dinosaur those days - and it's the duty of our team to make our Plasmic-Raptor intelligent as well.

Most of the Menu ideas comen up during the last year provided a "My Favorite" function, whereby the applications were added to it by simple click counts, saved in a ini based data base. The application with the highest click count was the Favorite.

But one big problem with this approach is that we are not collecting data about when each of the application are executed and how they are executed. What we found from Celeste Paul's (KDE Usability Expert) work on the Menu system Usability paper was, that Applications are executed more often using the command line on *nix systems, or via other methods like quick launch or desktop shortcuts. Therefor, the methods used for Kmenu will not work for Raptor.

Thomas Lübking was developing a new approach for this problem during the past year or so with his so called ALI menu concept and a prototype was shipped with his famous Baghira theme. In this section, Thomas envisions a new and unique solution to a prehistoric problem.

Here is the functional description he emailed:

Each entry is attached to a 24 elements vector (or a 2x24 matrix to separate week and weekend). The vector entries represent the probability of the app to be chosen at the current time (whether we scale it to [0,1] or [0,100] or [0,100000] doesn't matter at the moment) NOTICE that this is NOT the final rank! Everytime the user updates the filter string, the apps are matched against the filter string (IMPORTANT: one can save a lot of CPU by detecting filter refinements and check only the left apps. And presented ordered by their rank. (so the most probable app at this time that fits the editline->text() is displayed on top, it will make sense to limit the displayed app amount, say 20 or so)


There will be four conditions checked, concluded in the final rank.

1. Is there allready a RUNNING INSTANCE in most cases you won't open the same app twice via the launcher, e.g. konqueror opens new windows itself etc. - kwrite may be an exception beneath others what will hopefully (depends on the parameters) be catched by

2. The probability of the app to be running at THIS TIME from the 24v entries

3. The probability of the app to be run in THIS ENVIRONMENT This assumes that applications are usually called to work together. Examples: i often open kwrite to manipulate scripts or code and in addition a konsole to test them. - if you dial up, you'll have demand for konqueror/kmail after calling kppp, etc. Thus the AI will check for each candidate the correlation to other running apps (i.e. does the running time of the candidate cover the running time of the running app.

4. The probability of the app to fit the USER TYPE Simple keyword ranking: as keywords/tags should be attached to app entries (rather than a group entry, to allow multigrouping) we collect infos about what kind of apps the user runs through keyword probabilities (is he a developer, artist, scientist,... and does the candidate have this keyword) (We could bring in the keyword ranking here - what is currently NOT supported by the FDO desktop file definition


The running time stats:

The resolution will be hours.

- Everytime the user launches an app, its stats get a pushup during its runtime (so if the app runs from 16:00 to 18:00 the 16th and 17th entry will get a full pushup)

- Every new day ALL entries will be faded away (e.g. multiply by 0.9 - similar to the ant algorithm, a constant factor may be a bad idea ;)

- As the data is classified (24h entries instead of seamless or point information) we'll add the pushup to the hour entry relative to it's running time in this hour and read out it linearily combined to catch hour breaks


Assume the app runs from 16:13 to 17:48 and we grant a 10% pushup - i.e.
multiply with 1.1 for 1h runtime.
We'll grant (60-13)/60*1.1 to the 16th and 48/60*1.1 to the 17th entry.
When we wanna know the probability for the app to run around 16:42 will use
48/60*p[17] + 12*p[16] (i.e. a linear combination between the hour centers)
To clarify the reason: assume you usually run an app at 16:00, thus the
pushup goes to the 16th entry but should be taken into account when the app
is started on 15:59:59 once (this is an extreme example of course)
(This is not necessarily complete =)

Presentation (Technical part)

RaptorMenu Areas

There will be 5 basic areas of the Menu: The header, The footer, The categories pane, The elements pane and a shortstart bar. Each of them can be configurated seperately: will they be displayed (available for header, footer, shortstart), where, how many rows it contains (available for shortstart, elements) and which of the possible parts and plugins are loaded (does the header display a user logo or not, are there further plugins in the categories bar?, which buttons are displayed in the footer, lock, logout, standby, restart?)

This section aims to define the coding of the presentation of the above-mentionned Areas. Here are the first inputs, what it will actually contain:

  • A basic Abstract Item ( we already have this in the form of QGSItem, but we need to add some methods of it's own... so we need to inherit from QGSItem and make an abstract class). Lets call it RaptorVizAbstractItem class or some thing like this
  • Each Raptor item derived from this abstract items will be sensitive to input events. it will have support for displaying progress and ranking also and has to take in configuration options for each item: like delete / rename etc... There must also be accessibility options available like zoom level for each item.
  • We will use data structures to store such items ( maybe a link list connecting each of the items, so that item grouping is possible and it's also possible to apply input to the whole group ... We can also try to link multiple groups and stack in one on top of the other ... but this would be manged by a layout manager so that things are in proper order. this way we can also support moving a large view around like on kickoff... what we're trying to see is if we can try to move around in 3D... We're not sure yet :-) ... But based on Thomas comments, the AI agent will completely remove the need for a hierarchy in the menu, though we must still provide it as options to users who really want hierarchies.
  • Next...we will also have some special QGSItems for input fields and also for button types.
  • On top off all that we can have a 3rd Effects layer..where we can have some nice FX for those who like to have those. Water and fire are just two such things which would be nice... But it wouldn't be enabled by default... The user may enable it via config, if he wants it.

The Raptor Team

Note: The team is open to everyone who wants to contribute. Not only developers are welcome, but everyone thinking he/she can contribute (as for example Dracor, who doesn't code at all). So if you want to join, join the panel-dev mailing list and mention that you want to join the RaptorMenu team, as well as what do you think you can/will contribute (is it coding, a special area there, or is it helping to refine the concept?)

Plasma Team Lead:

Aaron Seigo

Raptor Maintainers:

Siraj Razick

Thomas Lübking


PhobosK (Co-Maintainter and Distribution Management)

Christoffer Brodd-Reijer (PSP integration and Backend development (Author of KPsPManager))

Buddhika "Bud" Siddhisena

Fathi "Fabo" Boudra

Yanis (Usability and Accessibility Development)

UI Design and Usability

Mensur "Nookie" Zahirovic

Documentation, technical docs

Nathanael "Dracor" Gogniat

Advice and Guidence and Development Support

Stephen Kulow (Kickoff)
Vandenoever (Strigi)
Raptor Thanks Oxygen-team for the extended support

Current State of the Project


  • In progress = +
  • Complete = *
  • Not started = -


  • Design of Menu AI Engine *
  • AI Engine Plugin +
  • Design UI (Nookie) +
  • Documentation (Dracor) +
  • Build System *
  • Initial porting of Applet code *
  • Raptor Button +
  • Raptor Layout Engine -
  • Raptor Rendering Engine -
  • Raptor DataEngine Loader -
  • Raptor Translations +
  • Raptor UML -

Progress Report Fri Sep 29 2006,

Things completed :

  • Port the initial applet code to KDE4 kicker . and loading the plasmoid has worked well.
  • Cmake based build system is working and initial folder structures are created. and commited to KDE svn trunk/playground/base/raptor/
  • Thomas is working on the AI engine and he has started work and we can expect to see a commit soon on svn
  • Nookie has made some mocks and in the process of completing the mock so that it can be published on the spec
  • Oxygen-team member is making a logo/icon for Rapor and initial contacts were made by fabo
  • The spec was read by Aaron and Vandenoever and waiting comments

Siraj Razick

Content is available under Creative Commons License SA 4.0 unless otherwise noted.