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