It’s good to see other parts of the OSS community looking at the current state of the X system tray and not be satisfied at all, it’s good because as you can see from this blog, i think the current approach is really really limited in many ways, as it was explained several times…
This time is about look… now, the idea of having monochrome systray icons is actually quite good, but is quite a pita with the current protocol and actually a good use case for the new one.. why?
Let’s say we have a black panel (as the mockup of jono’s blog), so it’s reasonable to expect we want white icons, but what about if we suddenly change our color scheme to a light colored one? (or plasma theme in case of KDE)
Of course the icons will become invisible, so we could need to change all of them to another theme on the fly, and this could mean also that those icons can’t belong to the system wide icon theme, or we could have to change the global theme just for the systray, that’s no good, right? 🙂
Now, the current systray protocol requires that is the application itself draws its own icon, and this theme-dependent icon color switching is kinda possible (just open the configuration of the panel… by every application) but it’s really clumsy and not cross desktop at all.
The dbus based systray protocol we’re working on requires instead that is the systray the one who paints all the icons, and being part of the panel of course it knows well what the color scheme is.
The icons can be sent in Dbus by data, passing all the icon bytes themselves and in this case of course we can’t do much more than painting what it arrives, but the recomended way is to just pass the icon name (following the icon name freedesktop spec of course) and in this way we can decide where to pick this icon, we could have systray-specific icon themes dependent from the color scheme (falling back to the system wide one of course)
Now, I don’t know if we’ll actually implement a thing like that and if it’s worth the effort, but it’s a while we are talking about that thing and i think soon or later I’ll give this idea a spin 😀
And this message is approved by Oxygen! 🙂 Realy it is there is no one design fits all and chaging the plasma theme as some contrast issues as the batery icon clearly shows…
When will KDE stop mimicking windows 7 L&F? With every release plasma theme looked more and more like windows, and now we have systray icons like that os. What’s next?
One good thing about KDE is: You can tweak it to look like whatever you want, so just go and change the look and feel!
In my humbly opinion, however, KDE (also in the default seeting) does NOT look like Win7, have you ever seen such an ugly control panel like the one from Redmond? It looks like a bad mockup.
Is the new systray used in KDE 4.3?
Totally agree with Vladimir.
Windows Vista has black taskbar, Oxygen had black taskbar, Windows 7 get transparent themes, KDE4 gets transparent themes, Windows 7 gets Aero Peek, KDE4 gets something similar, Windows 7 gets neatly arranged and autohidden systray icons, KDE4 does so too.
Makes you wonder that Pinheiro, Seigo and Martin must be practically living inside Ballmer’s rear end
… but stop insulting people who do all this work in their free time!
Maybe similarities are just due to something like contemporary taste, trends and the like.
Don’t all cars produced in one year look very alike? And didn’t the cars produced let’s say in 1950 or 1970 look very alike to each other, but not to the ones from 1990 or 2009?
> Is the new systray used in KDE 4.3?
yes, in an experimental way, some applications use it, on top of my head:
kmix,kwallet,nepomuk,kget,krandrtray and i’m pretty sure i forgotten something
target is to have a way more streamlined for 4.4
Oh yes, give it a spin !! I’d love to have sexy monochrome systray icons 🙂
Oh yes, give it a spin !! I’d love to have sexy monochrome systray icons 🙂
+1. Do it!
(Provided I understood it right) icon themes for the systray will have the problem, that they hardly cover all the systray icons out there. And so those not covered will look out of place. What about adding a monochrome icon to the spec and have apps provide it and then let the panel theme automatically color them in a matching color?
+1 for monochrome icons from me too! 🙂
Another thought on additional monochrome icons: This way the user could choose monochrome for status icons (think Mac menubar, multicolored icons don’t look nice here) and the normal multicolored ones for more application like systray apps (possibly in separate systrays). And IMO this needs to be forced somehow on the developers, otherwise you’ll never get a perfect experience.
The goal of Oxygen icon theme is as follows:
“Make a break with the past and go in a new direction, leaving behind the cartoonish and childish look of previous graphics”
-taken from Oxygen website
Now it appears to be different, when we have stripped down, simple monochrome icons. With just black and white, what can you really draw? Just outline, something simple, that’s all. Not something visually pleasing and realistic what Oxygen wanted to do.
And why do you do it then? Because Redmond thinks that’s the way to do it?
Also, i have a few more doubts about this not related to similarity to Redmond OS.
1) Was there any usability test to prove that this is in any way better than current approach? Here is one test for you. Use transparent panel and light (or dark) plasma theme, put monochrome icons in taskbar and put some wallpaper with bright (or dark) colors (like sky (at night)). Yeah, perfectly usable. And recognizing which icon represents what is even greater problem.
2) This will just alienate KDE from other DEs. The non-kde applications you run on it will stand out even more. How is that good? Windows 7 uses monochrome just for OS related stuff (like usb devices, network…), not every application.
KDE is really great, it pushed the desktop experience further, but really not every idea about a change is always good.
@Vladimir: Just for your information: OS X has monochrome systray icons for ages! And this is a) not Windows 7 and b) perfectly usable!