TelepathyUIComponents

Specification

Summary

This specification discusses common UI components that the Telepathy framework could make available so that applications do not need to implement them themselves, and the UI used to integrate Telepathy into the desktop.

Rationale

To extend Telepathy beyond its use as a backend for "traditional" IM interfaces like Gossip, there need to be bits of Telepathy user interface in any application that wants to support collaboration. The authors of applications that merely use Telepathy for collaboration shouldn't need to write these bits of UI themselves, with the resulting duplication of effort.

There still needs to be some specialized UI to do specific Telepathy things like managing presence, which should appear as part of the desktop environment.

Use cases

  • Simon is writing a specification and wants to indicate that he's busy. He selects the "Busy" option from a convenient menu in the notification area and his presence is set accordingly on all his IM accounts.
  • Jono wants to include a UI widget in Jokosher to select a contact for collaboration. He uses an existing library component to reduce effort and provide a consistent user interface.

Scope

This spec describes how Telepathy should integrate into the desktop (as opposed to in applications), and the reusable UI components that should be available for use in applications. Most of these plans are for something like the feisty+1 timeframe.

Design

(Where GNOME/Gtk things are mentioned here, there should be a KDE/Qt equivalent as well.)

We anticipate that the desktop integration will eventually include:

  • - a panel applet or notification area icon which indicates what your presence is, and can change it - presence UI, with contact list management - a gnome-control-center accounts capplet

There should be a Gtk library and a Qt library (provisionally, libtelepathyui-gtk and libtelepathyui-qt) containing common UI components, so not every client application has to reinvent the wheel. This shouldn't include UI that only ought to appear in one place, like the accounts control panel, but should include things that have to appear throughout the desktop in numerous collaborative applications.

Integration in the desktop

The presence applet replaces the notification-area icons currently provided by Gaim, Gossip et al, and serves the same purpose - it indicates your presence, lets you change your presence, provides a shortcut menu for common operations like opening the presence Ui, and is where notification bubbles come from. This could probably come from Gossip fairly directly. It should be started either during desktop session startup, or as a panel applet.

There should be some sort of presence UI (an applet and/or window analogous to the "main window" in current clients like Gaim and Gossip) showing a summary of contacts who are present; this should let you manipulate the contact list (subscribe to people's presence, manipulate groups, etc.). Again, the Gossip main window will hopefully evolve into this.

Other UIs dealing with people and contacts (Evolution, Contacts, etc.) should get presence information from Telepathy too, via Galago or directly.

While there does appear to be duplication, there is an important distinction between the list of contacts in Evolution Data Server, and the list of contacts in each Telepathy connection manager (and hence on the IM server). The former is a list of everyone you know about; the latter is a list of only those people whose presence you have asked to be informed about.

Mission Control

Mission Control is a non-GUI D-Bus service which:

  • - launches default or user-configured handlers when new channels appear other than by user request (for instance when a new text channel appears, it will launch an appropriate chat UI for the user's desktop environment and configuration) - stores the user's account settings - synchronizes presence (available/away/busy/etc.) - responds to signals from non-Telepathy sources by altering presence appropriately (e.g. set Away when the GNOME screensaver activates) - potentially, synchronizes personal information (vCards) and avatars between multiple accounts

(The Mission Control spec is currently under discussion, at http://telepathy.freedesktop.org/wiki/MissionControl)

UI components like the panel applet and the accounts capplet will communicate with Mission Control rather than being part of it. It's intended to be desktop-independent glue that ties things together.

Accounts configuration

There should be an Accounts capplet in the Control Center where the user can set up their IM accounts, which means this functionality doesn't need to be present in other apps.

The appropriate user interface for account names, and for the parameters passed to the CM to establish a connection, is protocol specific: for Jabber the account name needs to be a JID, for MSN an email address, etc. and the UI needs to provide hints/defaults/examples appropriate to the CM. In the worst case, parameters may be specific to the CM rather than the protocol, such as when CMs support different options or when CM authors don't use the conventional parameter names. The help and examples also need to be translated and localized.

It would be nice to have the UI packaged with the protocol (connection manager) for cases where some protocols can't be shipped (for instance Nokia can't ship anything based on reverse-engineered code in their normal install on the 770). This could take the form of a binary plugin to the accounts UI, or an XML description of the parameters.

If you have several connection managers for the same protocol, perhaps there should be a way to set priorities, though in the long term we hope there will be exactly one dominant connection manager per protocol.

This part of the UI could co-opt the "About Me" capplet to export vCards onto the IM services' user directories. There are privacy concerns here, and the user needs to be able to "opt-in" to us publicising their details, and choose between different profiles (personal and business addresses).

Address "profiles" may be a good way to address the privacy stuff - if the user wants to show their real name and email, but not their phone number, on the Jabber directory server, have them create a modified copy of their "Home" protocol called "Home (email only)" or something, and select "Home (email only)" from the drop-down list labelled "Details to make available on account 'jabber.org'".

Telepathy UI library

libtelepathyui should contain components like:

  • - dropdown list of protocols/CMs the system supports - list of connections available on the bus - widget to select a contact to communicate with
    • - list of contacts from address book - input widget for contacts not in your address book

      • - like the accounts capplet, this needs protocol-specific, and potentially even CM-specific, syntax help, which needs localization - for Jabber it's reasonably obvious that you need a JID, but for IRC it's less obvious how we represent a user, so the UI needs to tell the user to type name@irc.example.net vs irc.example.net/name, or provide "broken-down" name and server/ircnet inputs

    - "to send a message to this person you need to log in to the server, would you like to do so now?" UI - if the user says yes, it should ask Mission Control to establish the connection

Cohoba has some of this UI already which can be used as a prototype.

Implementation

There isn't a concrete schedule for implementation of these UI components - we're concentrating on infrastructure, like Mission Control, at the moment. We hope we can get community involvement in the UI development, e.g. evolving the Telepathy branch of Gossip to provide desktop integration.

CategoryTelepathy
CategorySpec

TelepathyUIComponents (last edited 2008-08-06 16:18:09 by localhost)