KDE/kdebase/workspace/plasma/applets/systemtray

Michael Rudolph michael.rudolph at gmail.com
Wed Jul 2 23:20:58 CEST 2008


On Wednesday 02 July 2008 20:18:08 Aaron J. Seigo wrote:
> On Wednesday 02 July 2008, Michael Rudolph wrote:
> > what would be the ideas and concepts behind this updated systemtray
> > specification?
>
> in a nutshell:
>
> * IPC based (rather than xembed)
> * all presentation and interaction is done by the systray host:
> 	* icon selection, with the exception of animations
> 	* mouse interaction
> 	* tooltip activation
> * systray client continues to provide app specifics
> 	* context menus
> 	* window activation
> 	* tooltip contents

Hello everyone,

ah, I understand. Just kidding; I just read the current spec this 
morning for the first time, so although I think I understand all your 
points here, I will not pretend to be able to follow this discussion. 
So extra thanks for taking the time and explaining it anyway.

The reason for my pointy-headed enquiry was, that given the time frame 
(4.3), I was hoping we could already be pushing something fundamentally 
better than a systemtray.

When I look at what a systray does or rather what it is supposed to do 
and than look at the possibilities we have with plasma, I wonder how 
useful it is to pursue this old technology.

If I'm not mistaken a plasmoid can take hints from its environment, like 
size constraints from a containment like the panel. But a plasmoid does 
not only adjust its size according to hints from its environment, it 
may also adjust its content. I think the analog clock looks different 
in the default containment than it does on the panel.

To me this already seems to be much more useful and flexible than even 
the updated systray spec would be. So wouldn't it be better to 
propagate a plasma-way of allowing contextual interactions with 
applications on the desktop, instead of reusing a systemtray?

Just my two cents.

michael


More information about the Panel-devel mailing list