Jump to content

Projects/Plasma/Menu

From KDE TechBase

Current Development

The Demonstration applet for Raptor can be found in KDE SVN (http://websvn.kde.org/trunk/playground/base/raptor/). You can run this applet under KDE3 to see few of the features we want to have on Raptor.

Pinheiro's mockups can be found at http://pinheiro-kde.blogspot.com/2007/10/raptor-join-fun.html.

The Page of the project can be found at http://www.raptor-menu.org .

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 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 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 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 =)

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.

TOM - Task Oriented Menu

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:

  • Be task oriented
  • Be simple and clear to use
  • Create a smaller but usable menu
  • Limited configurability through sensible defaults
  • Have all configuration needs built right into the menu, including:
  • Editor dialogs that can be called up from entries in the menu
  • Context menus accessed by RMB clicking on a task for powerusers
  • Allow locking down of menus through immutable settings
  • Obeys Kicker and KDE Kiosk settings
  • By making the TOM group of kickerrc immutable all config is removed
  • By making a task group's rc file immutable, config options are removed
  • Not require any modifications to the KDE menu system (applnk, etc)


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

  • Application launching should be caught somewhere in the KDE libs, ala

Recent Documents Writing out of config files to reflect runtime changes (deleted entries, etc)

  • This requires keeping track of the config files used in creating the menu

KDEDIR merging

  • KDEDIRS are already consulted for taskgroups, but groups of the same name

should be merged Sane merging of menuext entries

  • "Recent" items should go into the recent section
  • Replace TOM's builin recent docs with the menuext version?
  • Create a Recent Applications menuext?
  • Add a way to quickly add/remove menuext items from TOM

(ala "Modify These Tasks") Check for updates on launch and bring them down/install them if they exist

  • this includes new apps installed on the local box showing up in the menu
  • "Get cool stuff" integration?

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

  • Config is stored in an XML
  • This XML is saved by the config-sets name
  • This/these XML is/are read and delivered to KBFX via Plugin
  • The plugin should be able to merge multiple XML config setting files
  • KBFX should be able to run multiple TOM plugins
  • It should be possible to use further plugins right in the TOM Plugin -> The reasons are explained later

Store config as XML

  • Easy to edit
  • Can be extended in a simple way
  • Structured
  • Support for foreign charsets

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:

  1. Father, uses Office-Functionality, uses Graphics and his digicam, the Internet and occasionnaly plays games
  2. Mother, uses Office-Functionality, the Internet and occasionaly plays games
  3. 17yrs old son, geek and student, uses Office-Functionality, graphics and his digicam, the Internet, plays games, develops, and administers the computer
  4. 14yrs old son, student, uses Office functionality, Internet, plays games

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>
  <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>
  • The TaskGroup default attribute is the name used internally, not displayed
  • The locale default attribute is the iso code of the language, and is taken to display the names and descriptions according to the country settings. If no locale tag for the language is found, the language tag without language attribute should be taken - if one exists - or the one with the en attribute. The element itself should probably be in ""
  • The Program tag contains the command line to be executed upon launch
  • Probably, a sort order mechanism should be implemented as well, either with an tag or by means of a rating with tags
  • The XML should be UTF16 for foreign charset support

Things to be considered

  • One Thing that should be considered is that - as long as the XML's are not delivered by the distributors, it can happen that Programs disappear. The logical solution would be to mark them with white X in a red circle, and if one clicks on it, he is given 3 choices:
    • Search for the file that was linked
    • Delete the entry
    • Assign another Program to that task
  • Personal Setting files should be stored in /home/user/kbfx, and we should provide an export function that copies that file to /usr/share/kbfx somewhere
  • Loading should always have the two paths prepared as proposals for people to find it quickly
  • Having a possibility to enter plugins somewhere in tom would be nice and feasible, I think. Example: Tasks write (tagged , organize (tag , Contact (tagged with the information to hook that in. That could - when a contact plugin exists, listing contacts and possibilities to contact them - then let you contact the matching contact directly.
  • Instead of runtime-merging of multiple XML's, a personal XML could be created during the time you add another XML to the plugin. This - however - should have the origin marked to offer the possibility of sending these modifications back to the origin file.
  • To have a real TOM, we should also include a Plugin (right hooked into tom) importing the todo list of the user's PIM. It would then
    • launch the PIM, and display the task, if it has no attachments
    • Open the attached file, if one file is attached
    • Open a list with the attached files, if multiple files are attached
    • This came to mind as I do actually work with the todo a lot...

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

Developers

PhobosK (Co-Maintainer 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)

Dariusz "Malcolm" Mikulski

UI Design and Usability

Mensur "Nookie" Zahirovic

Documentation, technical docs

Nathanael "Dracor" Gogniat


Advice and Guidance and Development Support 

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

Current State of the Project

Keys

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

Tasks

  • Design of Menu AI Engine *
  • AI Engine Plugin +
  • Design UI (Nookie) +
  • Documentation (Dracor) +
  • Build System +

Progress (5. july 2007)

  • Raptor Widget Elements ---------------------60 %
  • Raptor Data Engines ------------------------90 %
  • Raptor Data Sources ------------------------60 %
  • Raptor Plugin Interface ----------------Complete
  • Raptor XML UI component --------------------50 %
  • Raptor Plugin TOM (Task Oriented Menu-------10 %
  • Raptor Apps Plugin --------------------------1 %

Progress Report Fri Sep 29 2006,

Things completed:

  • Port of 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 Raptor and initial contacts were made by fabo
  • The spec was read by Aaron and Vandenoever and waiting comments



Siraj Razick

Retrieved from "https://techbase.kde.org/index.php?title=Projects/Plasma/Menu&oldid=60934"