Version: unspecified (using Devel) OS: Linux Since I usually have Konversation hidden or obscured, I enable notifications so that I get informed whenever someone mentions my nick. When I get such a notification, I bring the window to front to read. Konversation should detect this, and stop sending further notifications. For example, during a conversation, it continues notifying me on each message I get that is prefixed with my nick. Once the window gets deactivated again, or after a certain time out, it could resume notifications. Reproducible: Didn't try
Hm sorry, I can't reproduce this. Notifications are only fired if the window is not the active window or the originating tab is not the active tab. Please post exact configuration details and exact steps to reproduce, since Konversation has such a multitude of notification systems (tabs, OSD, KNotify, etc).
Created attachment 49647 [details] konversationrc
Created attachment 49648 [details] konversation.notifyrc
That doesn't tell me to which type of notifications you're referring to, so I can only speculate: a) Tab label nick notification (colored text or LED icon) Tab notifications are only fired when the originating tab isn't the active one. Assuming there's no bug here, you can't mean those. b) The Konversation OSD nick notification When the window is the active one, the OSD is only fired when the originating tab isn't the active one. When the window is not the active window, the OSD is fired regardless of the originating tab. Again, so long as there is no bug here, you probably don't mean this. c) KNotify nick notification The KNotify notification is fired regardless of the tab or window state. That's on user request - the KNotify notification is the one you can get a sound with, and users have told us that sometimes they're doing things like watch TV in parallel and want Konversation to draw their attention back to itself even when the window and originating tab are active. Also, KNotify allows you to run an external program and hand it the text payload as argument, which some people use for various purposes, and hence they need to rely on the event firing every time regardless of window or tab state. This also has to be seen in historical context. Up until recently, the "Show a message in a popup" KNotify checkbox would show a KDialog dialog box window. Obviously that meant it was basically useless, and users clearly preferred the Konversaiton OSD. Today, "Show a message in a popup" shows a Plasma notification popup, which some users now prefer over the Konversation OSD for consistency with other notifications. Makes sense that this would mean some interest in KNotify behaving like the OSD does, and I speculate that's what your report is about. Unfortunately I don't see how to solve those competing requirements without stuffing another checkbox into the main config dialog, far away from the KNotify one and thus being completely undiscoverable, which is a bit frustrating ... Anyway, could you confirm you're talking about 'c'?
To state my wish differently: * I need an audible notification, because both the window and the system tray are usually hidden when I work, and I do not like popups. If I understand you correctly, this is only possible using the KNotify framework (option 'c'). * When someone pings me, I will eventually look at the window and start a conversation. During this conversation it is annoying when I hear the sound whenever my nick is mentioned over and over again. One possible solution for me would be a timer. When a new notification is issued within the same (say) 30 seconds, then it should not trigger the sound. That timer would be stopped once the window gets deactivated, so that I get further notifications again immediately. If this requires adding options to the UI, I have no problem waiting for the next release. After all, this is a wish not a bug :)
The problem is that the "Configure Notifications" dialog is a standard dialog from kdelibs and as such not extensible, and putting options related to those notifications far away from their GUI location into the main config dialog would be horrible for usability. At the same time I don't see how we could do this without adding any options -- even the timer thing you suggest above wouldn't work for those who rely on those events to fire absolutely every time. I wish KNotify had an built-in ability and option for this: When you fire a KNotify event you already hand it the window id of the associated window, so it could check whether the window is active itself. Oh well. One thing we could do is write a dialog that imitates the "Configure Notifications" dialog and place a KNotifyConfigWidget inside it along with some extra options. Also a pretty annoying hack, but far better from a usability POV. Actually, with the main config dialog dialog we have going on right now, I wonder if we could move the KNotify options into the main dialog outright by embedding a KNotifyConfigWidget, though that would break with the usual KDE convention of it being a separate menu entry in the menu. But we've had a lot of user problems with part of the notification options being in one dialog and the other part in another dialog for some time. Maybe we could move the KNotify options into the main config dialog, but still leave the "Configure Notifications" menu item and have it open the main config dialog on the right page ...
Changing ticket status.