The Demonstration applet for Raptor can be found in KDE SVN(http://websvn.kde.org/trunk/playground/base/kbfx_plasma/). You can run this applet under KDE3 to see few of the features we want to have on Raptor.
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 configured separately: 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 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 came 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. Therefore, 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)
Ranking:
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?)
=> NOTICE THAT THIS COULD DEMAND A GUIDE ON KEYWORD USAGE!!
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
Example: 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 =)
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:
What is TOM?
TOM stands for Task Oriented Menu and is a work in progress that will become a viable alternative to the current KMenu. Its goals include:
What is a "Task Oriented Menu"?
A task oriented menu displays it's entries as "things to do" (or tasks) rather than simply listing all items that are available. Each of these tasks has an application or command associated with it, and this associated command can be changed without changing the task name or placement within the menu. The tasks are grouped by function and may map to programs, documents or actions.
Todo list
Editor dialogs Make the Destination entries work (only Run A Command is done) Populate and track Recent Applications menu entries
Recent Documents Writing out of config files to reflect runtime changes (deleted entries, etc)
KDEDIR merging
should be merged Sane merging of menuext entries
(ala "Modify These Tasks") Check for updates on launch and bring them down/install them if they exist
Further refinement of wording / ordering in main menu (a perpetual TODO ;) Creation of real-world task groups Support plugins which can add arbitrary functionality to the menu
Debate list
What should be the default task entry format be: a) Task Name b) Task Name (App Name) c) App Name (Task Name) <-- silly option =) Should "Run A Command..." be replaced by an inline combobox? Pros: It's more obvious and will work even if kdesktop is gone. The widget is already written (in tom.cc) Cons: It makes it stand out too much over other entries, takes up more room and isn't as powerful as the full minicli
---Part above is pasted from a Mail from Aaron Seigo
Design and Architecture
Basic requirements
Store config as XML
Save by the config-set name
The idea is that one can easily transfer settings and import them to test without having to delete the carefully prepared own configuration.
This/these XML is/are read and delivered to KBFX via Plugin
The normal manner to make sure that changes and improvements can be delivered without actually touching the framework
The plugin should be able to merge multiple XML config setting files during runtime
Imagine a computer used by a group of persons. I explain by means of the following family:
They each have their own accounts. They each don't want to see the things they don't use. It would now be possible to have an XML for each of them. But 2 yrs later, the 17 yrs old leaves home, and the younger brother takes over system maintenance. Now he needs these progs. So the older one would have to set up the tom for system maintenance for his younger brother, who doesn't care of developping and gaming.
But if we provide possibility to hook in multiple XMLs per Plugin and merge them during runtime, they could have a baseXML with office and Internet functionality, a graphics XML for Graphics and Digicam, an XML for the games, an XML for developing and an XML for administration.
If a TaskGroup tag exists in multiple of those XMLs, it is only shown once, with the Tasks of all of those XML's. So the taskgroup could be "Write" and have the elements e.g. "a letter" from the office XML and "c++ code" from the developer XML. So redundant TaskGroups can be avoided and place can be saved.
Another scenario could be that a programmer writes a program set and -as enthusiast KBFX user- provides the TOM XML straight with it. No need to reconfigure KBFX TOM for the use with those programs, just hook in the new XML as well.
The Config editor should be able to merge multiple XML config setting fixed.
Now imagine that a user X is absolutely enthusiast of the program set of the above developer. But he has already created (for other programs) a task group name he likes better and also fits this developer's new program set. So he should be able to say "Import into XML", indicate in which Settings to import, from which file to import. He is then shown a list of all TaskGroups and Tasks of the XML with the import data, having checkboxes where he can select which parts (TaskGroups and/or Tasks) should be imported in the config editor, and subsequently, where in his original XML (for TaskGroups, which order, or as a subtaskgroup, for tasks into which task groups) he wants to import it to.
This makes the whole handling of new elements easier and gives developers the possibility to deliver the settings right with the programs.
KBFX should be able to run multiple TOM plugins.
That's a personal preference that - however - seems important to me. If we take the family from above as an example again. The older son - being a geek - loved tweaking the pc and did a lot of administration. The younger - in this scenario - has taken over the task of system maintenance. He is savvy enough to do it, but being no geek, it's just once in a while he touches the administration. In the example above, the old son had all in the things in the same plugin instance. He used system maintenance often, so it was not disturbing to have that lot of entries in his tom. The younger however, is a different story. As he only seldom does administration, it slows down his access to the things he really needs (by simply existing there) without bringing him advantages. So he unloads the administration XML, adds a new instance of TOM at the bottom of the KBFX Plugins and hooks it in there. He can now use the Tom at the top for his regular work and just once in a while opens tom2 with the administration XML to do system maintenance. It's still around, accessible in KBFX, but not there, where he usually starts the tasks he uses day by day, so without making him scroll longer for his applications.
XML Definition
I am no XML guru at all. I avoid the work to research a valid header definition. Instead I'll just concentrate on the content. The tags I use are (Please note that the text in red is the tags):
<TOM>
KDE TechBase <TaskGroup: Browse>
<Name>
<locale:de>Durchstöbere...</locale>
<locale:en>Browse...</locale>
</Name>
<TaskAction: Internet>
<Name>
<locale:de>das Internet (WWW)</locale>
<locale:en>the Internet (WWW)</locale>
</Name>
<Program>/usr/bin/firefox.sh</Program>
<Name>Firefox</Name>
<Description>
<locale:de>Surfen Sie im Internet</locale>
<locale:en>Surf the Web</locale>
</Description>
</TaskAction>
<Plugin: Contact>
<Name>
<locale:en>Contact...</locale>
<locale:de>Kontaktiere</locale>
</Name>
<PluginLoad>ContactPlugin</PluginLoad>
</Plugin>
</TaskGroup>
</TOM>
Things to be considered
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
Developers
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
Advice and Guidance and Development Support
Stephen Kulow (Kickoff) Vandenoever (Strigi) Raptor Thanks Oxygen-team for the extended support
Keys
Tasks
Progress Report Fri Sep 29 2006,
Things completed:
Siraj Razick
