notifications for non-plasmashell components

[David Edmundson]

On Wed, Apr 1, 2020 at 10:13 AM Bhushan Shah <bshah at mykolab.com> wrote:
>
> Morning,
>
> I was looking into notifications for plasma mobile lockscreen from last
> few days, current set of patches are in kscreenlocker, plasma-workspace,
> and plasma-phone-components.
>
> - https://phabricator.kde.org/D28455
> - https://phabricator.kde.org/D28454
> - https://invent.kde.org/kde/plasma-phone-components/-/merge_requests/68
>
> Current solution is rather very simple,
>
> - On getting a new notification, notification server checks for hint
>   which says if it should be on lockscreen?
> - If it is supposed to be on lockscreen, it talks to greeter dbus
>   interface and notifies about new notification or closed notification
> - greeterapp notifies the lockscreen theme using root.notifications
>   property.
>
> While this is implemented like this, I and Kai discussed several ideas
> on how to implement this best so that same solution can be useful for,
>
> - KDE Connect
> - Lockscreen
> - Latte dock
> - Sidebar/dashboard effects in store etc
>
> One suggestion which came up was API for notification handler plugins,
> idea being,
>
> - Notification server loads all the notificationhandler plugins
> - In KCM users would have option of selecting if appX notifications
>   should be handled by handlerY.
>
> Roughly something like,
>
> - Dialer
>     - [x] Show in lockscreen
>     - [x] Show in KDE Connnect
>     - [x] Show in Latte Dock
>     - [x] Show in applet
> - KMail
>     - [ ] Show in lockscreen
>     - [ ] Show in KDE connect
>     - [x] Show in Latte Dock
>     - [x] Show in applet
> .. etc .. (note that this config is something which might need some
> thinking from VDG/Usability teams)

I don't understand the case of latte dock being different to the applet.

But generally seems sensible. Though obviously this only works if the
notification comes from a KDE source.
>
> - Depending on this configuration, notification server would call
>   dispatch operation in plugin to send notification to the handler.
> - Handler can then talk to the application in either way they prefer
>   (dbus/wayland protocol/fd/whatever).

I don't think you need plugins if you have a DBus API.
Bhushan's just made a generic DBus interface for "watching"
notifications. I would make all handlers implement that.
Then the notification server just needs a list of servers+paths which
implement that notification watcher interface.

> There's another problem we discussed today regarding the current
> implementation of notification-on-lockscreen. Currently once greeter
> gets a notification from notification server, it would need some more
> boilerplate code to wrap the notifications in model and expose the
> notification features to the user interface. While it would be simple
> enough to add QALM/QAIM in greeter code base, this ultimately would end
> up being very bad copy of the libnotificationmanager and that too with
> incomplte features.
>
> Kai came up with solution to this problem which involves allowing
> NotificationsModel to depend on different implementation of source
> model then the current one. This source model would be listening for new
> notifications on greeter interface instead of directly talking with
> notification server.
>
> However we can't directly use the libnotificationmanager in greeter
> due to dependency loop, I can add very simple QAIM/QALM in the greeter
> source code, but that would essentially mean adding API for theme
> developers, and I am hesistent to commit to API since it is a) not
> future complete and b) there's better solution possible.
>
You can't at build time, you can use it at runtime. We use p-w parts
in the greeter already.

As long as the plugin is QML instantiatible, problem solved.  It might
need a bit more fleshing out of the lib to accommodate that.

David