Hi there,
That can be fixed in Settings >> Configure Konversation >> Behaviour >> General >> Only notify when a highlight is triggered or your current nick is used.

(note: I'm a Google Code-in student)

Ok. Seems solved now. Thanks.

But at this point the problem is the usability of the configuration dialog of konversation. There are three places where you can configure conversation notifications.

1) Settings > Configure notifications (that are overridden by 3 since some options are ignored)
2) Settings >> Configure Konversation >> Notifications
3) Settings >> Configure Konversation >> Behaviour >> General >> Only notify when a highlight is triggered or your current nick is used

The 3) is in a completely wrong place, because it's related to notifications

Moreover 3) should be enabled by default. I guess no one wants a constantly blinking tray icon.

I suggest to completely remove the options 'Use system tray for new message notification' and 'Only notify when a highlight is triggered or your current nick is used' and let the native KDE notification system handle this two cases (which are actually already present in the KDE notifications dialog)

There's a bunch of historical factors at play here:

a) When Konversation's notification features were implemented, KDE didn't have a notification frontend. Apps were left to display notifications to users in a nice way on their own; that's how the tray icon as well as the OSD came about.

b) The UI is subject to library limitations. The "Configure Notifications" dialog for KNotify-based notification events is provided by a library and not extensible. It's not possible to expose new notification types like "Show the tray icon" in that UI, that's why the UI is separate.

c) The different notification systems implement different behavior because they serve different use cases, some of which aren't obvious. For example, the "Configure Notifications" dialog offers notification types like "Speak text" (if KDE's text-to-speech system is installed) as well as "Command", which some users use as script triggers. Hence those events will fire even when Konversation is currently the active window and the event occurs in an active tab; the tray icon and the OSD, otoh, get to be smarter about avoiding situational noise. The text payload of the events also differs a bit due to the former.

Obviously it would be very nice to clean all of that up a little. We've long wished to reorganize the entire config dialog in general. Unfortunately getting notifications down to a single place used to be impossible however, because the KDE HIG proscribed "Configure Notifications" as a separate place in the menu, and with the dialog not extensible, anything it isn't good enough for has to be elsewhere. However, the HIG now allows embedding the KNotify-based event config in the main dialog. Unfortunately that still doesn't really enable making a unified page however, and simplfying the config needs significant work to disentangle the use cases mentioned (e.g. introduce a separate scripting system to get users to stop using notification events as triggers for them).

We've been repeatedly in talks with the then-current maintainers of KNotify to make KNotify as well as its config UI extensible, and some progress on this has been made. KNotify has a plugin architecture under the hood now, although applications can't install plugins yet. I've also talked with Martin Klapetek about allowing plugins to provide UI for event config and will CC him here again. I'm hopeful that eventually we can synthesize a clean path for complex notification configuration in KDE apps.

CC'ing Martin due to the above.

(Side note: I'm still on vacation until Jan 5th and won't be reading replies until then.)

Thanks for the detailed reply. It's instructive.

I've imagined that the historical reasons were the main cause and I can imagine how complicated can be to find an optimal solution for putting all this notifications configuration in a single place.

However I think the solution (temporary and dirty) I've suggested above can be made now, while we wait for a global better solution. 

The 'enable system tray' option should stay in the behavior subgroup, but the other two entries should be moved to a new system tray subgroup in the notification group, since they are actually configuration settings. In this way should be easier for the users to find them straightforward.

I've spent quite some time to figure out this problem. I though it was something about the entry 'New Message' in the 'Configure notifications' dialog that wasn't working and I completely didn't think that there exists a third place where to look for settings about notification. So I think other users can face the same situation.

(In reply to Eike Hein from comment #4)
> applications can't install plugins yet.

They can now, the headers are all public and stuff (or will be with frameworks 5.6, I lost track). You just can't configure them in the config dialog currently, that is true, however you can ship a .notifyrc file with that action hardcoded (or edit that file directly). But that's a workaround at best, yeah.

I'd still like to make that dialog properly extensible, but time's short... :/

Task bar entry blink for every new message ignoring actual configuration >

I've not seen this issue in conversation.

Simone can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I've set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.

I am not using Konversation much anymore, but I did a brief test and seems solved.