System Tray Programs

Duncan 1i5t5.duncan at cox.net
Tue Sep 21 00:36:56 BST 2010


Christian Mikovits posted on Mon, 20 Sep 2010 09:56:42 +0200 as excerpted:

> I'm using KDE4.5 with compiz as a Window Manager at the Moment and also
> was thinking of not using the kde-panels but tint2 instead. This very
> lightweight panel provides also a systray. But unfortunately not all
> systray programs show up in this panel, namely battery monitor, kmix,
> kbluethooth, knetworkmanager, klipper, kwallet and devicenotifier. Is
> there any possibility to bring these kde-tray-icons to any other systray
> than the kde one?

I believe Nikos is right, but am replying here as the quoting context is 
screwed up in that sub-thread (reply before quoted context, parts of the 
context trimmed, etc).

There's actually two or three (or more) different uses for the system 
tray, depending on how and what you count, and in kde 4.5, these are all 
controllable separately.  This requires an update to the legacy 
freedesktop.org system tray protocols.  Backward compatibility is 
maintained, but the core kde tray apps now use the new protocols and thus 
won't always be available when running legacy systray service providers.

1) There's desktop services, normally designed to start with the desktop 
and run as long as it's running, with little UI at all, except for 
control.  In kde 4.5, these have distinctive mono-color and transparant 
line-art icons.  Services such as kwalletd, klipper, the semantic desktop 
search services (nepomuk/strigi/etc) are included here.  I don't run 
knetworkmanager or kbluetooth and only run kmix on my netbook (my desktop 
has digital output to my stereo; kmix can toggle the digital out on and 
off but has no volume control for it, so there's little reason to run it 
on the desktop), which I haven't upgraded to 4.5 yet, so I'm not sure of 
their status, but from comments I've read, they're in this category as 
well.

It should be mentioned here that there's a new freedesktop.org standard 
evolving for this sort of thing.  Canonical/Ubuntu along with kde and 
gnome have been cooperating in developing this standard, which will 
encompass new protocols for both the services (category 1, here) and 
notifier (category 3) functionality.  It's **NOT** just KDE doing this 
alone, nor is it just Ubuntu, or just Gnome.  Ultimately both Gnome and 
KDE will have compliant implementations, with Ubuntu doing a somewhat 
different implementation as well.  Likely, other generally lighter desktop 
environments will follow with compliant implementations, just as they have 
in other areas, but I'm not sure how involved in creating the standard 
they are, or where they fall in implementation thereof, as yet.

2) There's traditional apps that many users run almost as services, often 
starting them with the desktop session and running them the whole time 
like desktop services, but these apps are far heavier than desktop 
services and normally have a full GUI.  Basically, the only difference 
between them and normal apps is that they minimize to tray and stay 
running, rather than entirely quit, when they are closed.  kmail, media 
players such as amarok (which I don't run), qmpdclient (since I run the 
far lighter mpd and various control clients instead), smplayer (a very 
nice and full-featured video player that replaced kaffeine for kde3, 
here), etc, fit in this category.  These apps need little more than the 
traditional freedesktop.org system tray standard and will likely continue 
using the legacy standard for some time, both because they don't need a 
lot more, and for backward compatibility purposes since they are often run 
on desktop environments (DEs) other than their native one, or because 
they're third party apps not associated with a specific DE.  The tray 
icons for this category remain full-color.

3) There's tray apps and services whose primary purpose is to allow 
notifications.  In kde 4.5, many of these don't even have their own systray 
icons, but instead, use the common system notification service.  It's 
possible some of the services in category one above will ultimately 
transition to this type.  The kwallet, device-notifier and desktop search 
icons are candidates for this.

4) There's apps that are borderline between the above categories.  Over 
time, these may be rewritten to share functionality differently between 
the main GUI app, the tray icon, and the system notifier, eventually 
eliminating the tray icon or switching it from a full app icon to a 
service icon, with functionality formerly found in the tray icon moved to 
either the GUI app or the common desktop notification system.  Obviously, 
apps which target multiple desktops are going to be a bit slower in 
moving, or perhaps have config options to keep more of the functionality 
in the legacy tray icon, for backward compatibility reasons.  But 
eventually, these new services will be as critical to a full functioning 
desktop as is the legacy systray service, today.

So bottom line, if you choose not to use the plasma desktop, and your 
replacement doesn't provide the new notification and desktop service icon 
functionality, you're going to lose the functionality which they provide.  
With stuff like kmix and knetworkmanager, there's other alternatives, 
other audo mixer apps (or just run the kmix gui, which should hopefully 
still run as a gui without the service, try invoking it twice in a row), 
other networkmanager apps, etc.  But of course, by choosing not to run the 
normal kde desktop, plasma, you're choosing to lose some of the kde 
integration it provides, and you can't expect a total replacement of the 
integrated look and feel.  But it's still your choice. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.




More information about the kde mailing list