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
signature.asc
Description: PGP signature
