Ayatana notifications for Plasma

[Dario Freddi]

Disclaimer: this mail is not meant to sound offensive and/or personal.

On Wednesday 23 September 2009 16:48:00 Aurélien Gâteau wrote:
> Hi,
> 
> I would like to present to you some work I have been doing for Canonical
> regarding notifications in Plasma.
> 
> Before going further, let me state that my goal with this mail is not to
> get this work incorporated upstream, as I understand the Plasma project
> have a different position than Canonical on the subject of notifications.
> I decided to write this mail because I believe it is more correct to let
> you know about it in a more "personal" way rather than you discovering
> it in a blog post or a Kubuntu review.

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.

That said.

> 
> This work provides an implementation of Ayatana notifications for Plasma
> (Ayatana is the name of a Canonical project to improve user experience
> on Ubuntu and derivatives). Ayatana notifications have the following
> characteristics:
> 
> - Notifications are queued instead of stacked. This helps reduce the
> "spamming" feeling.
> 
> - 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.

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.

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.

> 
> - 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?

> 
> - Since they do not need any interactivity interface, they are drawn
> using Plasma tooltip SVG.
> 
> Here are (slightly outdated) screenshots of what they look like:
> 
> http://people.canonical.com/~agateau/plasma-ayatana-notifications/powerdevi
> l.png
>  http://people.canonical.com/~agateau/plasma-ayatana-notifications/kopete.p
> ng
> 
> An important point: While the patch is integrated in Kubuntu, the
> default behavior is to use KDE notifications. The user can switch to
> Ayatana notifications through an option of the system tray configuration
> dialog (there are even preview buttons to help the user decide).
> 
> http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura
> tion.png
> 
> I attached a patch for you to test if you feel so inclined. I updated it
> this morning to latest trunk. It is a single large patch because I
> believe it is easier to try it this way, but if you are interested in
> the incremental steps, you can find a patchset tarball here:
> 
> http://people.canonical.com/~agateau/plasma-ayatana-notifications/
> 
> As I said I do not expect this to be merged but I would be very happy if
> some of you just gave it a try for a few hours and maybe find some
> interesting ideas in it. The queuing and click-through features in
> particular could be interesting.
> 
> I was quite skeptic about the idea of passive notifications first, but
> have since changed my mind after using them for a while. I believe this
> new approach needs to be tried for one to make an informed opinion on
> it. The feedback I got from Kubuntu Karmic users is varied: some like it
> a lot, other don't.
> 
> Please let me know your opinion on this.
> 
> Regards,
> Aurélien
> 

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090923/8eb21d11/attachment.sig