Plasma/Active/Contour/Technologies

Architecture Contour

Contour will combine existing KDE technologies with new ideas and approaches to handle the context data that mobile devices provide. The image below gives a rough overview of the components that make up a Contour-enabled system:

Architecture Contour

Core Components To Be Developed

Recommendation Manager

The Recommendation Manager is the heart of the Contour extension on top of Plasma Active. It maintains a list of recommended actions which are kept in sync with the current context of the user and the device.

To this end the recommendation manager constantly updates recommendations based on usage patterns, the current context, and recently taken actions.

Recommendations are passive propositions for actions or information that are there all the time. Recommendations change over time based on the changing context and detected patterns. Recommendations are not to be confused with system notifications for incoming calls, text messages, or events. They are non-intrusive and can either be accepted (activated) or ignored by the user. Ignoring a recommendation means to simply not react on it. Recommendations are specifically not yes-no questions.

Examples include Contact person X, Open file Y, Start playing music (this will take into account preferences of the user), Take note about the phone call just received, Open presentation for the meeting which you just entered, The next bus to X goes in 10 minutes (When in the office late at night).

Location Manager

The location manager monitors the geo location and manages known locations.

Here a distinction has to be made between the geo location expressed through longitude and latitude and a location like the office or the home town. While storing the former is very simple determining the latter is a bigger problem. This is where the location manager comes into play. It will make use of user feedback and statistical data to extrapolate locations.

At a later stage it can take information from online map services into account to determine the locations the device is currently at.

Location Storage

There are at least two ways to store the location:

• The current location can be stored in the metadata graph of each created triple. This would provide useful statistical data, allowing to evaluate where what has been done. This approach, however, only covers situations in which actual data is created in Nepomuk. In case the user just remains in one place for a long time but does not use their device no information is stored.

• The location can be stored independently from any other data and then be matched via the timestamp. This allows to store the location at any point but it also adds additional complexity as the system has to decide when it is of interest to store the location and when it is not.

In any case we need a QLandmarkManagerEngine that can store the created landmarks in Nepomuk.

Location Change

The most important task of the location manager is to determine when the device changes a location or when a new interesting location pops up. Possible locations that could be determined via geonames and contact information include:

• Cities
• Countries
• Locations like offices or homes could be extrapolated by statistical analysis.

If, for example, the user stays within a certain area for a longer time, and if in that time they even have a meeting in their calendar then the area could be used as basis for the meeting place. The system could either learn and improve the area based on additional events or ask the user to confirm.

Anonymous Locations

Locations are an important thing for better recommendations. However, users do not want to name each and every location they ever stay at. Thus, whenever the location manager detects a new location (typically since the device has not left a certain area for a longer time) this location is stored as an anonymous location. This means that it does not have a name yet. The user should get the possibility to set a name via a non-intrusive GUI element but does not have to. At a later point these anonymous locations may be looked up in a map service and automatically be linked to real locations like cities or shops or clubs.

Sensors Manager

The Sensors manager monitors the sensor information provided by the device. This includes device orientation, rotation, and so on. This information is accumulated and provided to the recommendation manager.

Technologies used in Contour:

Akonadi

Akonadi, the PIM storage and communication solution for KDE, is used for all PIM purposes like EMail, calendar, RSS feeds, and so on.

Akonadi already integrates with Nepomuk and, thus, provides all the information that is necessary for including PIM data into the recommendations provided by Contour.

Qt Mobility

Since one of the main goals of Contour is to integrate with Meego good Qt-Mobility support is essential. To that end a set of engines that store contact, organizer, or message data in Akonadi are implemented. This ensures that both Contour-enabled applications, KDE applications, and pure Meego applications use the same data, thus, providing the best user experience.

In addition to the PIM data storage the user context information from Qt-Mobility like geo location, orientation of the device, and so on is used in the Contour engine.

Plasma Mobile Shell

Text, text, text