Difference between revisions of "Projects/Plasma/NewSystemTray"

Jump to: navigation, search
(Draft of the D-Bus xml service description)
(Draft of the D-Bus xml service description: Fix broken link to spec draft)
 
(16 intermediate revisions by 5 users not shown)
Line 9: Line 9:
 
* System services
 
* System services
 
* Hardware
 
* Hardware
 +
 +
Applications registering with the system tray provide one of those categories. An instant messaging application or an email client will fall into 'Communications'. System services are for example software update notifications. Examples for Hardware are a battery monitor a mixer or a Network Management applet. Applications that use the system tray for freeing space in the taskbar use the Application Status category.
 +
The system tray implementation can choose to provide the information delivered by the client application in different ways.
  
 
== Properties ==
 
== Properties ==
  
A System Tray Icon will Have the following properties.
+
A System Tray Item will Have the following elements and properties.
  
 
* Icon
 
* Icon
 
+
** name
  - name
+
** pixmap (possible size variants)
 
+
  - pixmap (possible size variants)
+
  
 
* Tooltip
 
* Tooltip
 
+
** Headline
  - Headline
+
** Subtext
 
+
** Pixmap
  - Subtext
+
 
+
  - Pixmap
+
  
 
* Status
 
* Status
 +
** Passive (normal)
 +
** Active
 +
** Needs Attention
  
  - Passive (normal)
+
* Interaction
 +
** Context menu
 +
** Activate
 +
** Wheel up/down
  
  - Active
+
== Visualization ==
 +
The visualization of the registered application is determined by the system tray. It can be implemented as row or grid of icons, as in current system trays. The longer term perspective is to offer category-specific visualization for the applications.
 +
Applications that want to expose more control through desktop elements such as the system tray can choose to offer applets to support their specific requirements.
  
  - Needs Attention
+
== Interactions ==
 +
The interactions can be considered in terms of the 'Client' i.e. the icon itself, and the 'Host' e.g. the system tray.
  
* Interaction
+
Providing an interface for actions allows for coherent interaction across applications using the system tray.
  
  - Context menu
+
=== Client ===
 +
A client of the system tray is an application that registers with the system tray to display its information. The system tray (the host) reacts to signals it receives from the client. The host also can pass back an action to the client application, for example when the application has been activated. The host receives the signals in an asynchronous fashion from the client. The display of the message might happen delayed.
  
  - Activate
+
=== Host ===
 +
The Host is the system tray itself. It offers an interface for applications to register in a standardized way, acts on signals sent by these clients, and can do callbacks to the client application (for example to activate a window when the icon has been clicked).
  
  - Wheel up/down
+
==== Signals ====
 +
The application can signal the following to the system tray host in order to change appearance and status of the icon:
 +
* A new pixmap is available
 +
* The status changed
 +
* Show the tooltip contents (replaces "balloon messages")
  
== Interactions ==
+
==== Slots ====
 +
The Host (system tray) can call the following slots in the application:
 +
* activated
  
The interactions can be considered in terms of the 'Client' ie the icon itself, and the 'Host' eg. the system tray.
+
==== Properties ====
 +
The Host queries the client for the following properties:
 +
* tooltip data
 +
* name
 +
* pixmap
  
=== Client ===
+
= Implementation details =
 +
== Draft of the D-Bus xml service description ==
 +
A first draft of the xml describing the spec is here
 +
[http://websvn.kde.org/trunk/playground/base/plasma/libknotificationicon/org.kde.SystemTray.xml (websvn link)]
 +
based on
 +
[http://vizzzion.org/stuff/systray-whiteboard.jpg Whiteboard at TokamakII]. Documentation appropriate to xdg is being drafted [[https://gitorious.org/~notmart/xdg-specs/notmart-xdg-specs/blobs/master/specifications/StatusNotifier/specification.xml here]].
  
==== Signals ====
+
== Components ==
 +
=== SystemTrayDaemon Kded ===
  
- i have a new pixmap
+
It keeps the list of applications (dbus services actually) that want to use the systemtray, an application must explicitly register here to gain an icon. it's done outside the actual systemtray to mantain the icon list intact across different plasma sessions. Can be found [http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ somewhere in here].
  
- i have a new status
+
=== Protocol plugin in the Systemtray plasmoid ===
 +
For now it's called DBusSystemTray, can be found here in
 +
[http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/systemtray/protocols/dbussystemtray/ websvn]. It asks SystemTrayDaemon what the registered icons are and listens from it for new icons or removal of others.
 +
It will dialog with the applications using the protocol described in the above dbus specification.
  
the host will react to these, but with no guarantee of when - expect 500ms.
+
=== Client library ===
 +
[http://websvn.kde.org/trunk/extragear/libs/libknotificationitem/ (websvn link)]
 +
This library is aimed to be a drop-in replacement for KSystemTrayIcon and will talk to SystemtrayDaemon to register the app for the assignment of an icon in the systemtray and to the systemtray widget itself with the dbus calls defined in the protocol
  
==== Slots ====
+
== Features Moving From Applications to NotificationItem Visualization ==
  
- activated
+
=== Needs Attention Visualization ===
 +
Some applications provides options for how the "needs attention" visualization should be rendered. This should not be a per-application setting, but something in the visualization itself, allowing for consistent (between items shown) and flexible (e.g. tasks widget vs system tray widget) presentation.
  
==== Properties ====
+
Applications affected: konversation
  
- tooltip data
+
== Configuration UI Issues ==
  
- name
+
* The autohide settings are now a bit confusing as the user may see that it's not selected for autohiding, but the icon may itself choose to autohide and there's no way to override that
  
- pixmap
+
* selecting "Application Notifications" just turns them off in the system tray, it doesn't actually turn them off as it implies (at least to some of our users; bug reports have been made to that effect)
  
==== Draft of the D-Bus xml service description ====
+
= Further Reading =
[http://websvn.kde.org/trunk/playground/base/plasma/libknotificationicon/org.kde.SystemTray.xml Websvn link]
+
* [http://www.notmart.org/index.php/Software/Introducing_Notification_Icons notmart.org] Marco Martin: Introducing Notification Icons

Latest revision as of 01:28, 6 January 2012

Contents

[edit] New System Tray Design

[edit] Categories

System tray icons generally fall into four categories:

  • Indicators of application status
  • Communications
  • System services
  • Hardware

Applications registering with the system tray provide one of those categories. An instant messaging application or an email client will fall into 'Communications'. System services are for example software update notifications. Examples for Hardware are a battery monitor a mixer or a Network Management applet. Applications that use the system tray for freeing space in the taskbar use the Application Status category. The system tray implementation can choose to provide the information delivered by the client application in different ways.

[edit] Properties

A System Tray Item will Have the following elements and properties.

  • Icon
    • name
    • pixmap (possible size variants)
  • Tooltip
    • Headline
    • Subtext
    • Pixmap
  • Status
    • Passive (normal)
    • Active
    • Needs Attention
  • Interaction
    • Context menu
    • Activate
    • Wheel up/down

[edit] Visualization

The visualization of the registered application is determined by the system tray. It can be implemented as row or grid of icons, as in current system trays. The longer term perspective is to offer category-specific visualization for the applications. Applications that want to expose more control through desktop elements such as the system tray can choose to offer applets to support their specific requirements.

[edit] Interactions

The interactions can be considered in terms of the 'Client' i.e. the icon itself, and the 'Host' e.g. the system tray.

Providing an interface for actions allows for coherent interaction across applications using the system tray.

[edit] Client

A client of the system tray is an application that registers with the system tray to display its information. The system tray (the host) reacts to signals it receives from the client. The host also can pass back an action to the client application, for example when the application has been activated. The host receives the signals in an asynchronous fashion from the client. The display of the message might happen delayed.

[edit] Host

The Host is the system tray itself. It offers an interface for applications to register in a standardized way, acts on signals sent by these clients, and can do callbacks to the client application (for example to activate a window when the icon has been clicked).

[edit] Signals

The application can signal the following to the system tray host in order to change appearance and status of the icon:

  • A new pixmap is available
  • The status changed
  • Show the tooltip contents (replaces "balloon messages")

[edit] Slots

The Host (system tray) can call the following slots in the application:

  • activated

[edit] Properties

The Host queries the client for the following properties:

  • tooltip data
  • name
  • pixmap

[edit] Implementation details

[edit] Draft of the D-Bus xml service description

A first draft of the xml describing the spec is here (websvn link) based on Whiteboard at TokamakII. Documentation appropriate to xdg is being drafted [here].

[edit] Components

[edit] SystemTrayDaemon Kded

It keeps the list of applications (dbus services actually) that want to use the systemtray, an application must explicitly register here to gain an icon. it's done outside the actual systemtray to mantain the icon list intact across different plasma sessions. Can be found somewhere in here.

[edit] Protocol plugin in the Systemtray plasmoid

For now it's called DBusSystemTray, can be found here in websvn. It asks SystemTrayDaemon what the registered icons are and listens from it for new icons or removal of others. It will dialog with the applications using the protocol described in the above dbus specification.

[edit] Client library

(websvn link) This library is aimed to be a drop-in replacement for KSystemTrayIcon and will talk to SystemtrayDaemon to register the app for the assignment of an icon in the systemtray and to the systemtray widget itself with the dbus calls defined in the protocol

[edit] Features Moving From Applications to NotificationItem Visualization

[edit] Needs Attention Visualization

Some applications provides options for how the "needs attention" visualization should be rendered. This should not be a per-application setting, but something in the visualization itself, allowing for consistent (between items shown) and flexible (e.g. tasks widget vs system tray widget) presentation.

Applications affected: konversation

[edit] Configuration UI Issues

  • The autohide settings are now a bit confusing as the user may see that it's not selected for autohiding, but the icon may itself choose to autohide and there's no way to override that
  • selecting "Application Notifications" just turns them off in the system tray, it doesn't actually turn them off as it implies (at least to some of our users; bug reports have been made to that effect)

[edit] Further Reading

  • notmart.org Marco Martin: Introducing Notification Icons

This page was last modified on 6 January 2012, at 01:28. This page has been accessed 13,977 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal