[Native] Windows Notifications

[zbaylin]

@OhadRau and I were looking earlier at extending Notification to Windows support once #672 gets merged. (Sidenote, Linux is easy -- libnotify is very straightforward)

The problem is, as always, which API should we use? As of Win8+, there is a notification system similar to what is available on macOS, Toast Notifications: ToastNotification class. However, the primary support for this is for UWP apps. Here is a guide on how to use them with Win32 apps. There is also WinToast which is used by some pretty big projects it looks like (Git for Windows, namely), but I doubt we want to add this as a dependency (it remains an option though)

There is also a really primitive notification UI in Win7, but that's not really what the modern definition of "notification" is -- it's sort of like a quick reminder, i.e. battery low.

It's worth noting that Electron uses the Toast API, but that's likely because Chromium does. IIRC, in Win7-, they draw their own notifications on the screen like Firefox on Windows does now.

@bryphe and @Et7f3, I know you guys have more Windows experience, so if you guys have anything else to add, it would be very helpful.

Hopefully we can get this sorted soon so we can add the Windows implementation!

[OhadRau]

Yeah as Zach stated there's some concerns over what the right choice is here. Obviously tying into the native notification API is a very nice feature to have, but right now Electron/Chromium have to emulate it for Windows ≤7. The question here is what's the correct trade-off? Also, there's the possibility of supporting both APIs where we can do toasts when they're supported, otherwise fallback to the legacy notifications. With Revery still being so early in development and Windows 7 support ending, the long term compatibility looks good either way.

[Et7f3]

This seem usale for win 7, 8, 10 https://docs.microsoft.com/en-us/windows/win32/shell/notification-area

[zbaylin]

To quote @bryphe from the Discord:

@zbaylin - yep, good question! We should document them though. My goals are: - OSX 10.12+ - Windows 8+ - CentOS 7 (4.8.x c stdlib)

Which means I don't think the Win7 API is worth considering

[Et7f3]

It is also a C API that mean we don't get the overhead of the c# runtime.

[CrossR]

Just for additional (non-technical) consideration is that Windows 7 support ends early next year, so I would say there isn't much point spending time on something that is out of support on the 14th of next month.