[Panel-devel] Systray

[Vince Negri]

Aaron J. Seigo wrote:

>>B) discrete event notification / alarms
>>C) tiny pop-up GUI controls (volume, screen resolution, keyboard
>>mapping, ...)
> 
> 
> these are the only two things that should appear in the systray. and only the 
> most important items of type 'C' should be there. today we have waaay too 
> many type 'C' systray icons =/
> 

To recycle a (very fair) point Aaron made in response to my 
movable-notification-area musing, the plethora of type 'C' icons seems 
at least partly the result of the "because I can" factor:

"What better way to increase the c00lness of my first KDE app than to 
give it a systray icon! yay!"


The common streak in all "bad" type C icons is that they don't justify 
their existence in the systray when compared to the "good" type C's. An 
example of a "good" type C we'd probably agree on is the keyboard 
mapping icon: if you didn't have it, and had to go into Control Centre 
each time to change mapping, it would be an incredible pain in the neck.

"Good" type C's control things that really benefit from the extra speed 
of access (volume mute - is the phone ringing?) or require frequent 
access (keyboard map.) "Bad" type C's are often just slightly faster 
ways to change a setting you rarely change, so the real-world gain is 
negligible and outweighed by the systray confusion created.

Certainly, giving the user the ability to hide "bad" icons, or using app 
signing, will help; but we can only go so far in policing the contents 
of the systray automatically. So a certain amount of social engineering 
is required ;) For each "bad" systray icon, there's a reason - even if 
it's a bad one. [Most likely, the programmer found him/herself wanting 
faster access to something.] Plasma can offer improvements to general 
app handling, window handling, applets etc so that the programmer feels 
less need to jam something in the systray as a solution to an immediate 
problem.