On user notifications...

[Aaron J. Seigo]

On Friday, May 6, 2011 20:02:12 Martin Klapetek wrote:
> On Fri, May 6, 2011 at 19:51, George Kiagiadakis 
> > - 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.

yes, it would be nice to actually keep messages shown .. but only _some_ 
messages, and probably not simply at the app developer's random whim ("yes, 
make this one always shown" type flags will just result in all sorts of abuse)

 the additions to the galago spec that the gnome-shell developers added are in 
the right direction imo (even though it was done with _zero_ interaction with 
other users of the specification *growl*): mark what kind of message it is 
(e.g. IM) just as we do with the StatusNotifierItems (aka "the new system tray 
icons") and allow tagging the messages as being persistent or transient.

then the plasma notifications UI needs to gain support for that. tbh, though, 
we're all extremely busy on other tasks that require our attention right now. 
we'd be happy to help answer questions and guide people through making such 
feature additions, but i don't foresee us (plasma team) making them in the 
immediate future due to the current workloads elsewhere (combined with 
notifications essentially working well enough; if there are notifications 
needing attention the 'i' icon lights up..)

another nice thing would be to do as i did with the autohide of panels when 
there is something demanding attention: don't autohide until there is user 
interaction with the system. so if they are away for a while, nothing that 
needs their attention will have become hidden until they come back and have a 
chance to actually see it.

> > - 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).

this is the wish (or, if you prefer, fault) of the user and should not be 
worked around, imho.
 
> > 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

yep.

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

was it you who asked about his on irc earlier today, or is this just a popular 
question this week? :)

in any case, the fix would be pretty simple. the code is in kde-
runtime/knotify/notifybypopup.cpp .. at a quick glance it looks like simply 
checking for an icon on the KNotifyConfig* that is handed in to the notify 
method would suffice. perhaps this could even be done in the 
getAppCaptionAndIconName method.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- 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/kde-telepathy/attachments/20110506/94037156/attachment.sig