notifications for non-plasmashell components

[Bhushan Shah]

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)

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

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.

Any feedback on all of this?

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20200401/052e32e5/attachment.sig>