Application Panel Indicators

Inhaltsverzeichnis

Summary

For the Lucid cycle, the DX team is focusing on a part of the desktop that has become a problem-area:

disaster.png

The current notification area is more and more difficult for users to interact with. Each application behaves differently, they're not accessible, and they're even sometime styled differently.

We propose to migrate the different applets to using simple menus. This change should provide a more consistent interface and be an important step to improve the user experience with the right hand side of the panel.

To implement that change, we're proposing to use a set of dbus APIs. These protocols are based on current technologies, some already used in Ubuntu, others also discussed by members of the FreeDesktop.org group. This includes an implementation already validated by the KDE project.

We are providing a set of libraries compatible with the 2 major desktop environments, along with tools and documentation to help porting applications to use the new protocols.

This effort is managed as part of the Ayatana project group on Launchpad, joining other cross-desktop projects that were delivered during the last Ubuntu development cycles. See resources below.

Notification area usage analysis

The panel indicator area was introduced in an early version of Gnome, on the model of the Microsoft '95 design, as an area dedicated to notifications. It is often called the systray or the notification area.

Use cases

Generally it allows users to very quickly access important application features. For application developers, there are thus certain occasions were it's interesting to host some of the user interface directly on the panel:

Issues with the current situation

Over time the notification area grew organically and somewhat inconsistently, for example, by including various applets which, according to the Guidelines, do not properly belong in the panel indicators area.

panel-suck.png

1. The areas of the panel are not clearly defined or identifiable at a glance because items are no longer organised visually, behaviorally and logically. Each item seems to have an independent purpose and, when clicked, behaves very differently one from the other. We have buttons, menu-ish panel, menu-ish slider and menus. This makes it almost impossible for users to gain a clear overall picture of the function of that area.

2. Users expect items close to each other to behave similarly. They rely on the proximity of applets/applications/menus to predict their behaviours and explain their functions (Usability principles: 1) proximity compatibility (Barnett & Wickens, 1988; Wickens & Carswell, 1995) and 2) consistency (Universal Principle of Design; Nielsen Norman; Bastien & Scapin). The unpredictability of behaviours of items in the panel indicator generates some confusion since users are not always in a position to interpret what the system is doing in response to their actions.

Recommendations: Decisions have to be made about the role of the panel indicators area and items have to be grouped and organized with consistency as to goal, function and behavior in order to offer users a consistent, predictable and therefore intuitive experience.

Proposed changes

We propose to define 2 main areas on the panel:

Additionaly, we propose to turn all of the elements on the right side of the panel into regular menus.

panel-suck-less.png

This way, users will not have to worry about whether a function is accessible with a left or right click, or be suprised when a click on a panel icon suddenly hides or shows a full application window. Additionally, that will help provide:

Note: for compatibility reasons, we'll maintain a notification area zone for a while, to let application developers gradually migrate to the new protocol. Eventually, the old notification area should disappear and applications being able to inject generic/common functions in the system area, while the application-specific features will stay in the "application indicator" zone.

Software Architecture

During the Jaunty and Karmic cycles, we initiated a process to connect the panel and parts of the system using dbus. Traditionally the panel communicates with the rest of the system through a variety of technologies like: Orbit, X properties or Xembed. That flexibility has allowed a lot of applications to use the panel, but the general result is that this starts to show its age.

Using dbus for the panel. We've started with some menus (that we call indicators). We want to continue with all systray/notification-area applications. We call these application-indicators.

There are different parts composing the architecture required to implement the proposed solution.

We want to do this in a cross-desktop friendly manner that uses existing standards and is easy to migrate to. Therefore we propose this new method of application panel indicators.

In the implementation we developed for the Gnome desktop, we're reusing some existing technologies and introducing a new library.

Note: the extensions to KDE's KStatusNotifier API have been discussed with upstream developers in order to have cross-desktop compatible protocols. This way a KDE application running on a Gnome desktop will have its icon and context menu properly rendered in the Gnome panel. Similarly, a Gnome application running under KDE, should see its icon and menu rendered in the new systray plasmoïd.

Technical Resources

Design Guidelines

Currently applications set how they behave in the notification area. Some use it as a fancy minimize function, others shouldn't have icons in the first place, etc. The design team have put together a design document on how your application should behave.

Libraries

Get the code here or (browse):

bzr branch lp:indicator-application

We are providing sample implementations in C, C#, and Python using three applications: Rhythmbox, Tomboy, and jockey.

As of 2010-01-14, libappindicator now provides automatic fallback support in the absence of the application indicator area, ie you don't have to check for the presence of the applet in your code, the library will do that for you automatically. If the area is not present on the user desktop, the library will automatically rewrite "app indicator" calls to use the old gtk_status_icon / systray API. Also, libappindicator now provides transparent menu updates. This means that there's no need to do anything when changing a menu content elsewhere in an application: the library connects to gtk signals to trigger dbusmenu updates on the fly and refresh the icons and menus on the panel.

Automake fu

libappindicator is not yet a blessed dependency for Gnome (and won't be for the time being). So here is how third-party application developers can conditionally build for Ubuntu and use the new app. indicators.

WARNING: When using the Mono bindings for libappindicator, you have to check for 'appindicator-sharp-0.1' rather than 'appindicator-0.1'!

1. Test for the existence of libappindicator on the build system

APPINDICATOR_REQUIRED=0.0.7

AC_ARG_ENABLE(appindicator,

if test x$enable_appindicator = xauto ; then

fi

if test x$enable_appindicator = xyes ; then

fi AM_CONDITIONAL(HAVE_APP_INDICATOR, test x"$enable_appindicator" = xyes)

2. Enjoy libappindicator!

Public Package Archive(s)

We have set up a PPA with the core libraries needed for you to install and test libappindicator for Ubuntu Karmic. For Lucid users the libraries will be included in the distro by default. Adding this PPA, upgrading, and running rhythmbox will show you how it works.

If you are interested in porting and getting applications tested, we have set up an upstream applications PPA as a service to upstreams who want to get their applications tested. If you need help with this please contact JorgeCastro.

Bug reports, lists and IRC

Priority Applications

Below is a list of applications that need porting to the new API.

List of applications - Applications should also have a corresponding upstream bug report (Feel free to file and link them). When your patch is ready for review please submit it to the upstream bug tracker attached to the corresponding bug.

Name

Current behavior

Description of neccessary change

Blueprint?/Bug Report?

Blocking Bugs?

gnome-display-properties

Can provide a tray icon if the option is set in the main dialog. It provides a list of radio items and some (cairo drawn?) headers. The menu is the same for left and right click.

Just port the menu over (don't know if the headers can be ported over without an addition of functionality in libdbusmenu.

None

None

Porting Guide for Applications

The application indicators API is similar to the GtkStatusIcon API in some ways, but simpler and more opinionated in its design.

Indicators are grouped together by category, so it's important for the application to accurately specify its category. Possible categories for indicators include:

The category is set when the indicator is created and isn't changed.

Application indicators fall into one of three states:

The indicator status can be set using app_indicator_set_status().

The icons need to use icon names from themes, direct paths to icon files are not supported. For example, icon names used with gtk_status_icon_new_from_file() won't work.

Typical usage (C version)

Indicators should typically be created using the helper function app_indicator_new(). This returns a pointer to a newly created AppIndicator object, which is may be unref'd normally when it is no longer needed. This function expects three parameters:

The id parameter should be unique to your application. Because app indicators are cross-desktop, the icon_name parameter expects an icon name according to the usual icon naming spec. The category parameter is the indicator category as described above.

Once an indicator object is created, the application may decide to set an attention icon using app_indicator_set_attention_icon().

Lastly, the indicator should be given a GtkMenu object. This can be either created manually or using some other method such as GtkUIManager. Below is an example using GtkUIManager.

Zeilennummern ein/ausschalten

Python version

PyGI

Zeilennummern ein/ausschalten

PyGTK

Zeilennummern ein/ausschalten

C# Example

Zeilennummern ein/ausschalten

Vala Example

Zeilennummern ein/ausschalten

Haskell example

Zeilennummern ein/ausschalten

Custom Fallbacks

By default the Application Indicator supports a fallback which will create a GtkStatusIcon with the same icon as the Application Indicator. It supports the menu and responds to all the same state and icon changes. For most applications this should be complete sufficient for their needs. Some applications may wish to handle the callback slightly differently than this. In that case the fallback functions are provided in the class structure so that they can be subclassed and overridden.

There are two functions fallback and unfallback. In general, the fallback function should setup the fallback scenario and the unfallback will take it down. Unfallback will be called if the application indicator returns or at shutdown if that never occurs.

For a very simple example of a fallback function you can look at the fallback test that creates an object overriding the fallback and unfallback functions. Also, the code in the Application Indicator itself for the fallback and unfallback functions was designed so that it only uses Public API functions so it can be copied directly and modified.

You can also use the 'connection_changed' signal to watch changes to the connections.

Treatment of the API

Menus should be presented from lowest Position value on the leading end, to highest Position value on the trailing end. If an indicator does not declare a Position value, it should fill the 32-bit integer with the most significant byte being filled by the category: 0 for APP_INDICATOR_CATEGORY_APPLICATION_STATUS, 40 for APP_INDICATOR_CATEGORY_COMMUNICATIONS, 80 for APP_INDICATOR_CATEGORY_SYSTEM_SERVICES, 120 for APP_INDICATOR_CATEGORY_HARDWARE, or 160 for APP_INDICATOR_CATEGORY_OTHER, with the remaining three bytes filled by the first 3 bytes of the application name.

The title of the menu should consist of the icon represented by IconName, followed by the text in Label if any. If that text is wider than 6 em, it should be cropped at the trailing end.

DesktopExperienceTeam/ApplicationIndicators (zuletzt geändert am 2013-04-11 13:15:38 durch 3v1n0)