On user notifications...
George Kiagiadakis
kiagiadakis.george at gmail.com
Fri May 6 19:51:31 CEST 2011
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?
Best regards,
George
More information about the Plasma-devel
mailing list