system tray work

[Aaron J. Seigo]

On April 29, 2010, Marco Martin wrote:
> that i icon, is the most fixed, always there icon of all, since the systray
> is usually at the right side it stays indeed always fixed (apart when the
> expander appears/disappears)
> if the important area is at right, i fear it would appear way too jumpy,
> since it would move on each icon apearing/disappearing.

since things tend to grow towards the middle (due to the tasks widget being 
the one with the most room to offer being in the middle) this could indeed be 
an issue. it's a simple set of changes to flip it back at this point, though, 
so let's see how it goes and if this does become a problem, deal with it then.

> other than thatm it would make more sense, but it seems kinda a "visual"
> blocker (note that if the problems are those nitpicks is a sign that we
> have pretty much successfully fixed the severe ones :p)

;)
 
> > * increased consistency in interaction; i really dislike krandr's window
> > now
> 
> the icon, context menu or the kcm than gets open?

the icon is the obvious one but i know that will be worked on. it's more the 
rest of the interaction: it's the only one that opens a full window when left-
clicked, that window doesn't get focus (often it's hidden in the back of other 
windows for me), each click pulls up a new copy of the window, the menu 
doesn't work when the window is showing .. and of course the UI is really not 
user friendly in general.

this really has little to do with the system tray work, though, other than the 
icon.

> * klipper.
> right now Fredrik has an almost-complete port to kstatusnotifier, however
> there is a feature that can't be ported to it:
> the klipper menu can be opened with a keyboard shortcut, and is possible to
> set it to open at the systray position or at mouse cursor position.
> with kstatusnotifier is possible only to open it at mouse cursor position,
> since you can't know the icon position.

could the KStatusNotifierItem request the menu to be shown, and then the 
visualization could do the work? this "breaks" when there is more than one 
visualization and would mean adding a feature in the spec that is pretty 
highly specific to one item..

*thinks*

another option would be add a feature to the system tray itself that allows 
assigning a keyboard shortcut to any icon. then klipper doesn't need to 
implement that feature (and can just keep the "open at the mouse cursor 
position" feature).

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks