Ubuntu Wiki

• Launchpad Entry: kubuntu-ayatana-integration

• Created: June 17, 2009

• Contributors: ScottKitterman, David Barth, Aurélien Gâteau, Sebastien Kugler, Roderick Greening, and lots of others .....

• Packages affected: Several

Summary

This spec describes the intended approach for Kubuntu, Ayatana, and KDE to work together to deliver an improved user experience for Kubuntu (and KDE) users. The proposed approach is intended to balance the interests of all three developer groups to make the best improvements for the user.

The default user experience for Kubuntu will (as it has in the past) be managed by Kubuntu developers with oversight from the Kubuntu Council to resolve disputes. As Ayatana developments relative to KDE/Kubuntu mature and are accepted (or it becomes clear they will be accepted) upstream, these developments will be considered for backporting or early inclusion in the release.

An option (or set of options) will be provided to allow users to enable specific Ayatana developed enhancements. The goal is to engage users to try some new and exciting things and give feedback to Ayatana, KDE, and Kubuntu. By engaging users to opt in to these new features, we expect them to be open to new ideas and ready to give something better a try.

As much of the KDE specific development work as possible will be done in an upstream KDE repository (e.g kdesvn) to ease transition to upstream and to gain a broader constituency for the development work. The desired end state is thatl most or all of the code related to proven ideas will merge into the regular KDE code base and not be maintained just by Canonical.

Release Note

Kubuntu Karmic includes, for the first time, optional new features to enhance the user experience developed by Canonical's Ayatana project. These include .... To give them a try ....

Rationale

The planned approach balances Kubuntu's traditional community focus and commitment to delivering a pure KDE experience with Ayatana's charter to boldly explore new frontiers to improve the free desktop experience. Upstream KDE is interested in learning lessons from this experiment and is open to feedback on how to make KDE even better in the future.

User stories

Assumptions

Design

All three projects agree on certain high level attributes of the user experience. These attributes need to be documented and agreed. This attribute list will evolve over time. Changes must be by consensus. A governance process needs to be developed. An example of an attribute of the user experience would be "The user should not feel rushed by ephemeral notifications."

All three projects are interested in harmonising low level protocols and infrastructure so that applications can operate with minimal concern about what desktop environment is currently active. Work on this area is primarily upstream work that should be carried on outside the distribution context with entities such as freedesktop.org.

In between these two aspects there is considerable room for each desktop environment to provide an experience that is true to its values.

For the Karmic release cycle we want to present our users with two broad options for the provided configuration:

1. Kubuntu standard based on the KDE upstream as default

2. Kubuntu enhanced by Ayatana as an option that is easily configurable,

• reasonably discoverable, and with a good feedback mechanism

Kubuntu and Ayatana will work together to make sure that changes from Ayatana that are acceptable to upstream for merging into upstream releases (future or targeted at the current Kubuntu release) are integrated into the Kubuntu standard experience when it is technically reasonable to do so. It is not unusual for Kubuntu to backport features from future KDE releases when it is of benefit for Kubuntu users and in that respect this is no different.

Implementation

One of the attributes of the user experience that we have strong consensus on is that the user should have a coherent experience based on the desktop environment they have chosen. In Gnome, the experience should be consistently Gnome like and in KDE, the experience should be consistently KDE like.

Since applications in Ubuntu have been patched to expect the presence of a message indicator, everyone is in agreement that Kubuntu should have a message indicator that is KDE native.

UI Changes

Enabling the Ayatana experience

The user should be able to easily switch between Kubuntu or Kubuntu + Ayatana. Proposed solutions to do this are:

• A Plasma widget installed on the default desktop
• A KDM session
• A new systemsettings module

Which one should be used must be discussed with usability people.

Unifying notifications

Work is currently being done to improve the freedesktop.org notification spec so that KDE can use it. When this is done, and patches to implement this in KDE are accepted for KDE4.4, they can be backported in Karmic.

Work should also be done to make Qt notification system use the freedesktop.org notification spec as well.

This will result in unified notifications on both the KDE and Gnome desktop, regardless of the toolkit used by applications.

Volume and brightness

Work will be done in upstream KDE to show notifications as a feedback for volume and screen brightness changes. These changes can then be backported in Karmic.

Ayatana notification behavior

Ayatana vision of notifications differs from upstream KDE vision. The Ayatana experience will bring some changes in the way KDE notifications behave:

• Action-less notifications will be visually different from actionable notifications. They will probably look like Plasma tooltips.
• Action-less notifications will be kept in a queue rather than stacking.
• Action-less notifications will be click-through: moving the mouse over the notification will hide it, and clicking will go to the window underneath.

Messaging indicator

A KDE version of the messaging indicator will be implemented as a Plasma widget. This will allow a better integration of libindicate-enabled applications.

To reduce the amount of changes to KDE applications, actionable notifications may be converted into entries in the messaging indicator widget, if available on the desktop. The usability of this change needs to be reviewed.

Some KDE applications may still need to be explicitly changed to take better advantage of the message indicator.

Test/Demo Plan

TBS

Unresolved issues

Aspects of this plan are a moving target since this is a first effort.

CategorySpec