Ayatana notifications for Plasma
aurelien.gateau at canonical.com
Wed Sep 23 19:17:02 CEST 2009
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
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
>> - 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
More information about the Plasma-devel