On Wed, Apr 1, 2020 at 10:13 AM Bhushan Shah <bs...@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
