Add support for sound capabilities

[lenemter]

Closes #124
Fixes #158

Unfortunately GLib.Notification doesn't support setting hints and libnotify has bad actions support so I didn't add tests for this to demo. But I could find this website which has a test for silent notifications: https://web-push-book.gauntface.com/demos/notification-examples/

Not ideal but better than nothing. If we want our demo application to support sound capabilities, we would have to manually send notifications via DBus but I'd prefer to implement this in a separate branch

[danirabbit]

I think libnotify is no longer maintained and targets the old abandoned spec. But the portal spec
seems to describe a sound property, so probably this should be available over libportal?

[lenemter]

@danirabbit I don't like using libportal for this since it has an additional step of processing on the portal side and it doesn't support all the things from freedesktop spec.

Application -> Portals -> org.freedesktop.Notification
vs
Application -> org.freedesktop.Notification

We should implement org.freedesktop.Notification in the notifications server. Notification Portal spec should be implemented by Portals by converting portal notification requests into org.freedesktop.Notification ones

[danirabbit]

I disagree. I don't think we should implement an old spec that app developers can't use. We should implement just the features that apps in flatpak can use. Otherwise we're writing things that we can't document or recommend in any way and I don't think that makes sense

[lenemter]

We should implement just the features that apps in flatpak can use

They can use it through sandbox hole and some apps do exactly that.

Overall stripping our notification server into serving only the portal spec is unrealistic since we would need to rewrite large part of it and break every second application while doing so.

[danirabbit]

App developers aren't supposed to add sandbox holes though. We can't write app developer documentation that says, "break user's ability to control which notifications they receive so that you can access this feature". We need to be part of the solution, not part of the problem. And yes that does mean breaking old applications that aren't updating to modern APIs. That's part of our duty as platform developers, otherwise we undermine the efforts of other freedesktop members

[lenemter]

@danirabbit I'm not saying that we need to ask developers to add sandbox hole. Honestly I'm not sure what you're trying to achieve here. Notifications server doesn't control Notification portal and we're waiting on elementary/portals#128 to remove dependency on Gtk Portals (which relies on "old spec" to convert notifications from portals)

What I'm trying to say is that we currently just can't use portals here since it's not related to notifications server. And if we want to merge notification server with notification portal we would need to rewrite the whole thing

[danirabbit]

@lenemter im trying to make sure that if we add a feature to the server that app developers can actually use it. We need to have some recommendation that we can document for this feature. So developers need to be able to use either glib.notification or libportal.

If app developers can't access this feature, we shouldn't add it. It would just be dead code

[lenemter]

@danirabbit This is out of scope of notification server, portal spec is controlled by portals and currently notifications server doesn't control it.

We can add support for sound capabilities for portals only after elementary/portals#128

[danirabbit]

@lenemter okay so let's revisit this after portals is updated so we can make sure we have a path for documentation etc