(*** This bug was imported into bugs.kde.org ***) Package: kicker Version: 1.1 (using KDE 3.0.3 ) Severity: wishlist Installed from: Mandrake Linux Cooker i586 - Cooker Compiler: gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) OS: Linux (i686) release 2.4.19-5mdk OS/Compiler notes: It's not clear to users how to configure the System Tray. I have KCPULoad and the keyboard-changer deal now I remember KCPULoad was unintuitive... It would be good to have a menu or something with a list of all the applets that could run here... Also I recall some applets are hard to get rid of. This is very Windozy. All the applets should be easy to remove permanently and all the same way. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
The application that puts things in the system tray is responsible for their UI, so if there are issues with a specific item, report it to the associated application.
From the USER's standpoint, there is no way to make a given item appear in the system tray at startup, nor a way to make one that is there stop appearing at startup. This is a functionality that, from the USER'S perspective, should be associated with the system tray itself.
Well, you both are right, bascially. Perhaps one could add a way for the applets to "register" somewhere or let them look into a text file or sth to know if they should appear in kicker? cheers, RichiH
*** This bug has been marked as a duplicate of 57729 ***
This isn't quite a duplicate of 57729. This report proposes that the user should have direct control over what appears in the system tray, whereas 57729 suggests it should show the "mostly used" items. Besides, this was reported nearly a year earlier! I wonder, what is your criterion for determining what report is a duplicate?
don't reopen bugs i've re-assigned, especially as duplicates, unless you wish to implement the patch yourself. in which case, attach the patch to the bug when you reopen it. otherwise, leave it alone. i have reasons for merging duplicate bugs, and believe me, this is a duplicate bug. i don't care that one says "user control" and the other says "automagic management" because i as (one of) the developer(s) knows the solution i'm working towards (which happens to be both) and want to keep all the bug reports for this sort of icon hiding/management together so i have the whole problem and reports in one BR. thank you =) *** This bug has been marked as a duplicate of 57729 ***