Native notifications

So the native OS notification PR (#3389) is currently on halt due to unclear requirements. I would like to get back to developing on it, but we first need to resolve some questions:

• How should the public API look like? Where should notifications live? How should we identify notifications (for instance when receiving an close/dismiss event)?
• How should the application be registered with the OS? On Windows (10) it’s required to install a shortcut that is associated with the “AppUserModelID” of the application. On OSX it’s required to install a bundle identifier. In both scenarios we need a way for the user to provide input for this registration process.
• Where should the NativeNotificationManger live? @kekekeks argued that it should be on the TopLevel. I recall that @grokys did not really like this (?).
• What about Windows8/8.1? They both seem to have (partial) support for the ToastNotification API but supporting Windows 10 is certainly easier due to the convenient Microsoft.Windows.SDK.Contracts package.

We should probably figure out the application registration before everything else. Also instead of making a giant PR with all platform support we should start slow with Windows (10) support and ship other OS one-by-one.

Any thoughts?

[pr8x]

For anybody interested: I put most of the code from the PR in to a standalone library for now. https://github.com/pr8x/DesktopNotifications

Closing this ticket for now.

CC: @nitanmarcel

[kekekeks]

Fire-and-forget approach leads to swallowed exceptions. Why is everyone so obsessed with sync APIs? You aren’t writing winforms code in 2002 anymore. Anything outside of plain computations is asynchronous in its nature. Writing to disk? Async. Network? Async. GPU rendering? Async. IPC? Async. Communications with the window server? Yes, you’ve guessed it, they are async too. Some systems try to hide those async APIs behind sync facades which leads to numerous issues like app freeze when attempting to access clipboard.