I see last entry sparkled a bit of discussion, so a recap is needed on what are the goals of our redesign for the ground up of the systemtray, form the low level protocol to the visualization.
The systemtray was almost always intended as a “notification area” (this always was its official name) and most implementation until now failed at it. The Windows systray failed because every commercial application wanted to put its “brand” on it, the X11 systemtray failed even in a worse way, because there was zero communication between the applications and the systemtray and there was no semantics at all in the items.
So the visual representation had to be pretty limited, it could just put there all the icons that registered themselves and nothing else.
The “notification” nature was failed by the fact that is was just an huge disorganized list of everything and the kitchen sink, so the option to manually hide some of them got in. This was again a failing of the notification concept, a manually hidden notification item can’t notify anything right?
But hiding icons would not be a bad thing if you can ensure that the ones that are actually notifying something are indeed visible, so -manually- hide/show icons can’t work.
That’s one of the reasons we wrote a whole new protocol for those items, called StatusNotifier (and -not- sytemTraySomething), this is already being implemented from third parties, for instance the next Ubuntu release will make extensive use of it. In the new protocol, an item is in a passive state unless it decides it really needs to be active (i.e. has some useful status information, like the battery charge) or is notifying something really important (like, the battery is running out).
Any information that doesn’t belong to the latter two cases, simply should not be there, as well doesn’t belong there its usage as a tiny taskbar, that will go completely away in the future (probably to go on another widget or in the taskbar itsef).
As a result, the visualization (that is what’s is improperly called systemtray) now can use much more data than before and can give to the user a representation that makes semantically sense, like showing only “real” notifications in the notification area.
Now the hidden items are a menu, because since an hidden item means it has no notification value, it just have an “interaction” one. so you probably need to access it just to trigger a function, like accessing one of its menu items (that will become a submenu of the main menu) and not anymore.
This design is a radical departure from the previous one (I would go as far as saying that is not a systemtray anymore, or at least that should be the target), so in the current Plasma widget there will be no room for the old behaviour anymore (so no configuration option to make it behave like a totally different widget, that should indeed be shipped as a different widget). However, the modular nature of Plasma, makes it really easy to replace the widget with a different one, maybe derived from the 4.4 branch (that by the way will stay buildable for the whole 4.x lifetime), so if there will be enough demand, rest assured a different widget for your needs will be available somewhere.
Thanks for the update on this. It sounds interesting, but what are the plans for the following three cases:
a) Non-notifications from KDE SC: For the time being, the tray provides space for things like klipper and kmix, which don’t use it for notification. I have a lot of interaction with both (especially klipper), where would they go?
b) Notifications from outside KDE SC: Will GNOME support the same ideas? Right now, pidgin is sitting in my tray. It basically is using it for notifications (new messages), so it would probably work well with your plans.
c) Non-notifications from outside KDE: There are other apps out there relying on the X11/”old KDE” way of putting a small, constant interaction window (what you call tiny taskbar). For example, I use the java app DavMail to access an MS Exchange Server, where would that put itself?
Would I need to run a second widget, e.g. “systray 4.4”, next to the new notification widget?
a) kmix is an hardware status item, just like the battery, could be always quite important (for instance if you’re in a conference knowing that the audio is not muted, so potentially annoy people is veery useful :))
instead klipper should really become a plasmoid, some day or the other 🙂
b) yes, for pidgin it would work wonderfully, if they will adopt the protocol
c)the current thing will have to support the legacy protocol for the time being, so no worries here, what could happen in the future however is those icons moved from there to ome other place (still not sure where or if it will be the case)
It is a great idea to have one place where you can see right away all the apps / functions what are notifying something. You do not get a pop-up but just the icon there.
But there really are some problems with some functions, just like the mentioned KMix, Battery, Networking (wireless), Klipper, Instant messenger (status) etc.
I have currently only three on systray. Kopete and KMix. I have a cable modem so I do not need a network status there. But I do need to see what is my current status in IM. And Klipper I have on mouse shortcut so I can cast it anytime. I needed to place Klipper to systray permament view when I had old mouse without fifth button while my primary was on repair.
There was a early KDE 4.0 mockups on kde-look what were animated. Where was the Kopete etc popping up when needed to notify user.
http://kde-look.org/content/show.php/Kde4+Mockup?content=28476
http://kde-look.org/content/show.php/Mini+Audio+Applet?content=34884
http://kde-look.org/content/show.php/KDE+Extender+Mockup?content=30012
Those two last are what I think Selene illustrated as well about week ago.
…the battery widget is *not* only useful while it is “notifying something really important (like, the battery is running out)” – it’s also nice to be able to look at it at any time to see the current battery loading progress.
Similarly, as another commenter already mentioned, an instant messenger systray icon is not only useful for showing important notifications (like new messages), but also for displaying the current status at any time.
Similarly for other widgets also.
In general, I think you new approach focuses much too exclusively on the “notification” acpects, and totally forgets about the “status information” aspects of such system-tray-or-whatever-you-want-to-call-them icons.
I agree with the last comments. The problem is that if the new “unsystemtray” can only hold notifications what’s the place for tasks running in the background which the user usually don’t want to see in the task manager because he barely interacts with them? It’s worth noting that those tasks are the ones which usually generate notifications.
Examples of those apps are music players, instant messaging applications, download managers, peer to peer programs, personal file servers, mail checkers, battery monitors,… I think that for a number of them the user may be interested in what’s the current status of the application and sometimes he may want to interact with it so, where they should go now? And, if they find a new place wouldn’t it be strange when their notifications appeared in the notification area instead of where those applications are now?
In fact there are 3 stages: the battery is passive (hidden) when there is no battery, active, when there is a battery and the charge is normal, notifying (in last position, blinking, whatever) when it’s running out
kopete in the same way is always active, because it always tell useful information and notifying when somebody writes a mesage.
decision when an item tells useful information or not is up to the app writer, really
So, in a sense, the notification area will still work a bit as a tiny taskbar. 🙂
(I think that’s unavoidable)
Anyway, after reading your explanation I think it makes sense and it’s certainly an improvement. Thanks!
>Now the hidden items are a menu, because since an hidden item means it has no notification value, it just have an “interaction” one. so you probably need to access it just to trigger a function, like accessing one of its menu items (that will become a submenu of the main menu) and not anymore.
And what about icons, that reacts differently on right-, and left-mouse-click? Will they be able to do it, when showed in the expanded “hidden items” menu, or they will loose this ability, and be a plain “submenu triggers”, without right- and left-click actions?
For example – keyboard layout switcher. Now it allows to change layout on left-click, and change some options on right click. This is pretty convenient.
Good observation about the system tray being misused for branding garbage under Windows. This situation should be avoided on the design level under KDE and your proposal is going in the right direction.