Hello!
http://www.kde.org/announcements/announce-4.5-beta1.php

A reworked notification area. Thanks to the new, D-Bus-based protocol that replaces the old "system tray", a uniform look and consistent interaction scheme can now be guaranteed across applications and toolkits.

Here we can see a "new, D-Bus-based protocol that replaces the old "system tray"".
Please, tell me some more information about it, how it called, it's API or at least some sources of it...

Please see http://freedesktop.org/wiki/Specificati ... tifierIcon

bcooksley wrote:Please see http://freedesktop.org/wiki/Specificati ... tifierIcon

Thank you. I'm already read this. May I ask more specific questions?

1) If I running (for example) system without KDE4 or Gnome, or even pure X-server with only window manager (not KWin, or it's required?), which daemon providing access to D-Bus based notification area? Which software I should start to get access to tray icons from my Qt program (with D-Bus)?

2) https://launchpad.net/ayatana
Or it's needless to know API of this new notification area and I should use special library for this? If so, where I can get this?

Sorry for these questions, but I need "notification area" in my custom desktop environment, so I'm curious about how to get support of this in modern way through D-Bus...

KDE has a class which dynamically falls back to the XEmbed based system tray if a D-Bus system tray isn't available.

In the KDE Workspace, the functionality runs as part of KDE Daemon ( kded4 ) but is only activated if a full KDE session is detected. KDE Daemon implements the StatusNotifierWatcher part of the specification.

If you are writing your own Desktop Environment, you need to implement the StatusNotifierWatcher and StatusNotifierHost components.

If you are writing an application, you should fallback to normal XEmbed based system trays if StatusNotifierWatcher is not available. When it becomes available, you should automatically switch to it however. There is a class in KDEUi, which provides this functionality to KDE applications.

bcooksley wrote:...
If you are writing an application, you should fallback to normal XEmbed based system trays if StatusNotifierWatcher is not available. When it becomes available, you should automatically switch to it however. There is a class in KDEUi, which provides this functionality to KDE applications.

Thank you! It's exactly what I need. But since it will also be available in Gnome and others, I expected that there are something DE-independent daemon.

Whether there are API between StatusNotifierHost and StatusNotifierWatcher, is it documented or I should read sources to implement this protocol? Some DE-independent implementations of this "host" is available?

Linux777 wrote:But since it will also be available in Gnome and others, I expected that there are something DE-independent daemon.

The DE independent part is the D-Bus API, GNOME might even have two implementations of it (one for GNOME panel and one for Shell).

Some of the other DEs (e.g XFCE, LXDE) might have implementations that are stand-alone reusable in yours.

Cheers,
_

anda_skoa wrote:

Linux777 wrote:But since it will also be available in Gnome and others, I expected that there are something DE-independent daemon.

The DE independent part is the D-Bus API, GNOME might even have two implementations of it (one for GNOME panel and one for Shell).

Some of the other DEs (e.g XFCE, LXDE) might have implementations that are stand-alone reusable in yours.

OK, last question... All implementations of "D-Bus notification area" based on XEmbed in their internals? So, it's just a modern interface to it?

No.
The old notification area implementations are based on XEmbed, this D-Bus API is a new alternative that allows better consitance in visualizations and behavior (controlled by the host, not by each client).

Implementations such as Plasma's provide both mechanisms, i.e. the XEmbed one as a fallback in case the application doesn't support the D-Bus one yet.

Cheers,
_

anda_skoa wrote:Implementations such as Plasma's provide both mechanisms, i.e. the XEmbed one as a fallback in case the application doesn't support the D-Bus one yet.

Ahhh... It must be supported by application also... Everything clear now, thank you all!