notifications for non-plasmashell components

[Bhushan Shah]

On Wed, Apr 01, 2020 at 10:32:40AM +0100, David Edmundson wrote:
> I don't understand the case of latte dock being different to the applet.

I believe it is separate process, no?

> But generally seems sensible. Though obviously this only works if the
> notification comes from a KDE source.

Right, we could instead have a global toggle, so that you can do,

Show Notifications:
- [x] Lockscreen
- [x] KDE connect
- [ ] Latte Dock
- [x] Plasma

And possibly blacklist for individual plugins... anyway this is mostly
UI/API bit and not huge issue to design one way or another.

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

Problem with dbus interface we realized was, either a) we need hardcode
of every possible handler in notification server or b) have some kind of
handshake/user approval stuff.. and both were pretty meh/unsecure.

But I am open to ideas on how this can be handled without hardcode.

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

Kai had some reservation about API/lib changes (check the backlog of
#plasma IRC channel today, alternatively Kai can explain this best).

> 
> David

Cheers!

-- 
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/31c727a1/attachment.sig>