[Konversation-devel] [konversation] [Bug 342388] Task bar entry blink for every new message ignoring actual configuration

[Eike Hein]

https://bugs.kde.org/show_bug.cgi?id=342388

Eike Hein <hein at kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hein at kde.org

--- Comment #4 from Eike Hein <hein at kde.org> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.