On user notifications...

[Martin Klapetek]

On Fri, May 6, 2011 at 19:51, George Kiagiadakis <
kiagiadakis.george at gmail.com> wrote:

> Hello fellow plasma developers,
>
> I am writing you, with my kde-telepathy developer hat on, to ask for
> some advice regarding some design issues we have in the kde-telepathy
> project regarding user notifications.
>

> As we already know, the current knotify & plasma notification system
> allows us to define events that can be shown as popups on the tray,
> played as sounds, etc... This is a good approach for some kinds of
> notifications, which are passive - i.e. do not necessarily require
> user attention, such as showing an incoming instant message or a job
> completion notification, etc.
>
> However, we are currently in need of showing some notifications that
> must *not* be passive - i.e. the user should notice them and act on
> them. Some examples are:
>
> - Incoming file transfer: "User foo is sending you a file. accept/reject"
> - Incoming audio/video call: "User foo is calling you. answer/reject the
> call"
> - Incoming desktop sharing invitation: "User foo wants to share
> his/her desktop with you. accept/reject"
>
> Unfortunately the current notification system is not good enough for
> those, because:
>
> - Plasma notifications autohide (and there is no way to keep them
> persistently shown, even though there are options for that in the
> KNotification API and the .notifyrc files...). This is a problem
> because if the user is not looking at the screen when the popup is
> shown and it hides before the user has a chance to see it, he won't be
> notified of the event.
> - It is possible from systemsettings to turn off the popups and let it
> just play some sound for example, which leaves the user with no way of
> accepting/rejecting the request (and the daemon that shows the
> requests has no way of knowing that there is no popup actually shown).
>
> Typically, this is solved with dialog popups. krfb for example does
> this, and I think kopete too. However, I think that this is not the
> right solution in a modern KDE plasma desktop, as it is too intrusive
> (stealing focus, etc...), let alone that kwin by default does not
> allow such popups to steal focus and get on top, which means that they
> are hidden behind the active window and the user still doesn't get
> properly notified.
>
> So, I think that the proper solution would be to extend the plasma
> notification system somehow so that it supports such notifications.
> Any thoughts? Have you ever had anything like that in mind when you
> designed the notification system?
>


I would also like to use this thread to add one more thing we encountered
with kde-telepathy. The contact list has two types of notifications - error
and info (I hope the meaning is obvious). We have two events defined in the
.notifyrc file, one for each notification type. And now we would like to
assign different icon to each notify event (one for errors, one for info),
but this is currently not possible, because one can set only one icon in
the [Global] section. Therefore we could really use (and I believe not only
we as kde-telepathy) if the icon could be specified per [Event/..] section.

Would this be possible as well?

--Marty


>
> Best regards,
> George
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20110506/7954fd7f/attachment-0001.htm