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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
