Ayatana notifications for Plasma

[Aurélien Gâteau]

Dario Freddi wrote:
> I'd like a bit more clarity. The patch you posted about powerdevil was 
> presented as "your initiative" regardless of Ayatana. However, with Ayatana 
> notifications user interaction is not possible, hence your previous patch was 
> either an unfortunate wrong timing coincidence or strictly related.
> 
> I don't want to go off-topic or whatever, since about your PowerDevil patch I 
> am quite confused as I really can't decide between a notification and a 
> dialog, but I'd just like to have some clarifications on purpose and goals.

I wrote the Powerdevil patch because the notification annoyed me a few 
times ago personally, but also because it was a problem for Ayatana 
notifications. Note that with Ayatana notifications, I mean either 
notify-osd or the Plasma patch I posted.

I should have mentioned it in my first message, and I addressed this 
(probably not enough) in one of the answers I made to Aaron, where I 
mentioned the Powerdevil notification was a bigger problem for Kubuntu 
users running notify-osd.

I have been preparing the email about Ayatana notifications for a few 
days and wanted to keep them separate, but when I read Sebas mentioning 
Ayatana notifications, I decided to rush it out because as I said, I 
thought it would be more correct if I presented this work to the Plasma 
devs myself.

I am sorry for this bad timing. I really did not try to have the 
Powerdevil patch upstreamed before presenting the Ayatana patch.

>> - Notifications are passive: they do not feature actions or close
>> buttons. This is probably the most controversial bit.
> 
> What about IM? Without what you presented in your post about Indicators, the 
> desktop workspace would be broken. Hence this makes me really believe you're 
> taking the wrong route here. You are basically pushing 2 different kind of 
> notifications (with 2 API and 2 underlying systems) the developer has to 
> choose (and learn) to display informations.

Yes, the indicators are meant to complement the passive notifications.

> And the situation of PowerDevil is the one that demonstrates the weakness of 
> this design. Putting aside the scope of the notification, the side effects and 
> whatever, my question is: would it be possible, with the current Ayatana spec 
> featuring indicators to achieve something like powerdevil notification without 
> a dialog? I bet the answer is no. Indicators would be too much, and with this 
> spec you are defining (IMHO) the following points:
> 
>  1 - Everything that requires user interaction can be delayed until X - wrong. 
> Unless you decide that in situations where the user has to provide fast 
> feedback you want to use dialogs
>  2 - Everything short-noticed should be passive - wrong. It's instant 
> messaging for a reason :) Indicators might fit for mails, but if I'm using an 
> instant messenger I want to see the message on the fly, be able to view it if 
> I want (by clicking the notification), or simply let it fade out.

This was my exact feelings before giving the passive notifications a try.

What I realized is that active notifications introduce a urge to act: 
you must act by clicking the button before the notification goes away.

If you are using passive notifications plus a system like the 
indicators, you do not have this urge to act: you can read the IM text 
of the notification and take your time to act because the indicator will 
provide you a permanent access to the incoming chat message.

> So it looks like this design is lacking a middle-way of doing things.
> 
> Aside from that, having 2 (!) servers handling notifications is what I call 
> bloat. Especially now that we're targeting small devices where powersaving and 
> resource consumption DO matter.

They are just applets listening to DBus communications. I would not call 
this bloat (what I would call bloat is not having indicators and 
implemented in term of systray, but that's another story). On a really 
small device, neither KDE nor Ayatana notifications will fit the needs 
anyway.

>> - Since notifications are passive, they are click-through: when you move
>> the mouse over them, they fade away to become almost transparent and let
>> you click through them to reach any underlying window.
> 
> Nice indeed, but is that what the user expects? What if the user wants simply 
> to close it without waiting for the timeout?

The need to close is usually motivated by the need to reach what is 
under the notification. Using it for a while I did not felt the need to 
close them.

Aurélien