I just read about Colibri and that motivated me to write a blog post I wanted to write for a long time. First of all I think it’s an improvement that the Ayatana notifications are now packaged and not patched into the system as in Karmic – one of the reasons why I am using Debian, now 😉 (I still think that notifications are a central part of the workspace and that a downstream should respect it’s upstream’s decision on that point.)
But that’s not the point of this post. I want to talk about click through. Aurélien advertises the Colibri notifications as click through, that you can interact with the window underneath. I think that is the failure by design of the Ayatana notifications. The fact that it’s missing actions in the notifications is just a consequence of it.
So what’s the problem with the click through? It requires compositing. A click through is only useful if the window you click through is translucent. But we do not always have compositing. There are systems where it still doesn’t work – even new ones. There are users who don’t want to use it and there are situations when kwin just turns it off due to bad performance.
Consider the situation that you are a user of a non composited environment and the notifications are shown on the upper right as in Aurélien’s screenshot. A notification appears and you click on it so that it goes away, because you do not know that they are queued. The window underneath the notification will be closed in the worst case if the click hit the close button. That’s probably not what Joe User expects. So when the environment is non-composited a click-through is a no go. The same is true if the notification is opaque or hardly translucent. But based on the description they fade away, so that is not a problem.
A solution to the non-composited environment is to make the notifications not click through when compositing is turned off. But that has drawbacks as well. Consider the situation that an experienced user knows about the click through and suspends compositing (something I do quite often). Now a notification appears and he wants to interact with the window underneath as he knows the geometry. The click is eaten by the notification although he expects that it goes through. So in that case we have a behavioral change which is in my opinion as bad as the not expected click through.
So we see as soon as compositing is turned off it breaks. So the fault in the Ayatana specification in my opinion is that functionality depends on visual representation. I’m pretty sure such a mistake would not have happened in Plasma as there are devs who can’t use compositing: "Erm you want to do that? I don’t have compositing that wouldn’t work for me." In kwin as well we ensure that compositing only adds additional features without breaking anything if compositing is turned off that is all compositing features are optional effects.
And just to make sure: this is of course no critic to Aurélien’s work. AFAIK he joined Canonical after the spec was designed and he just implemented the KDE part. I also appreciate that Ayatana is now using KDE’s status notifier spec instead of inventing yet another solution. So most of my critics on Ayatana’s approach which drove me away from Kubuntu are not valid any more (except the point mentioned in this post).
=-=-=-=-=
Powered by Blogilo
Right now, when running on a non-composited display, Colibri hides the notification when you mouse over it. This is of course less nice than fading out, but I believe it provides a reasonable fallback.
At one time I was thinking about implementing a non-composited-display friendly animation, something similar to what Kicker in KDE 3 was doing with tooltips, but in the end I thought people running in a non-composited display are probably low on resources, so it made little sense to implement this.
Ok that is a workaround and while an animation would be helpful I agree that it is probably bad for ressources.
Another option for non-compositing systems is to still change the visual representation of the notification without compositing. For example, keep a thin border of the notification and hide the centre. There is still a visual indication that the notification is there, but it is obvious where the click will go. Although this may not look good. I guess it would require mockups and tests.
I think this is a very good idea. With compositing disabled, it’s annoying that the notifications just disappear when you mouse over them.
On the other side we have Plasma 4.4 notifications wich requires a LOT OF EFFORT to make them disappear, even if they are purely informative like kmail’s ones.
I really do hope that’s a kubuntu’s packages problem or it’s a known bug that’s going to be solved cause in plasma 4.4 notifications are pretty unusable (aka ayatana is way better)
Well that is Beta 1. Try again with Beta 2 – it got some good improvement.
Vide, don’t worry because there are people working on improve the current Plasma 4.4 notifications, and I can assure you that they won’t come out in the current state.
Btw, a few hours ago notmart modified 3 lines which improve the situation a lot 🙂 so don’t worry they won’t be that painful.
afiestas and martin: ok, thanks for the info… cause right now I’m using gnome (don’t want to mess with packages to downgrade to 4.3) as shell, although using as always almost only KDE applications.
I’ll wait for beta2 to see if other bugs as well are fixed (right know even with a fresh user plasma-desktop is not executed on login, I’ve to alt+f2 and launch it manually, it’s really strange, CPU consumption is 4-5 times higher than with plasma 4.3 and so on…)