warning notifications

[Antoine Martin]

If something goes wrong, the message ends up in the console output and server log (via remote logging), but most users won't look there and will therefore be unaware of the problem.

We should add an option to allow notifications to be used for major events, ie: another user joined the session, file uploads (#1375), the connection is having problems (#401)

The initial warnings during the client startup could be bunched up together to avoid spamming the notification system with multiple messages on startup.
In any case, this should probably be rate limited and controllable from the system tray menu.

Links:

• ​electron notifications (Windows, Linux, macOS)
• ​electron-notification-state links to the apis needed to honour "do not disturb" mode on win32 and macos

See also: #1492, #1305

[Antoine Martin]

Large change in r18110: refactoring + a user joining the session will trigger a notification message sent to:

• all other connected users for seamless sessions
• the session itself for shadow sessions

Still TODO:

• tie the notification to our tray (on win32)
• send notifications to the user whose connection is having problems (congestion events), rate limited
• maybe file uploads - though #1375 already provides a dialog..

[Antoine Martin]

• r18111 + r18113: the notifications are now tied to our system tray on win32
• r18116: refactoring preparation for bandwidth congestion warnings

Still TODO:

• better bandwidth congestion detection: the heuristics may be improved (detecting late acks) and this should fire the "congestion" handling code
• maybe add a way for us to intercept the notification "action" response, so we can fire code server side?

[Antoine Martin]

• related network improvements: ticket:619#comment:12
• heuristics improved in r18138
• lots of bandwidth detection improvements: see ticket:999#comment:44
• discovered a bottleneck with opengl: #1754

[Antoine Martin]

• mostly done for bandwidth issues in r18194 (#401 closed as a duplicate of this bug): when we detect multiple network congestion events (more than XPRA_CONGESTION_WARNING_EVENT_COUNT=10 in the last 10 seconds) we send a notification to the client with an optional action to lower the bandwidth limit. We use #1676 to keep things in sync with the client, works for "bandwidth-limit", adding support for changing the "min-quality" using a notification action would require a bit more work.

The new "-d bandwidth" debug switch can be used to see how we try to manage the bandwidth.

• done for idle-timeout (#803) in r18200
• see also ticket:1492#comment:9 (win32 clients will now show notifications actions using the gtk notifier).

From now on, we can easily add more warning notifications as we go along.

---

To test:

• XPRA_ACK_TOLERANCE=0 may be enough to go over the threshold, or lower XPRA_CONGESTION_WARNING_EVENT_COUNT, and/or use a bandwidth limiter (see #417), then generate lots bandwidth (ie: glxspheres): notification allows the client to lower the bandwidth limit (unless it is already so low it cannot be lowered)
• enable sharing and connect with more than one client: notification shows details about the new user connecting
• start the server with: xpra start --idle-timeout=20 and connect a client (you should be able to cancel the timeout)

All of this should work equally well on all platforms, including the html5 client. But full backwards compatibility with older clients is not possible and those will just not be aware of the notification actions.

[J. Max Mena]

Okay I've tested this on every platform I have available to me immediately:

• Fedora 26 (r18247)

• Win8.1 (r18200 beta)

• MacOSX (r18200 beta)

• I made the mistake of clicking the update button thinking it would only take a few minutes. Boy was I wrong. I won't be making that mistake again.

Everything appears to be working as expected. Is there anything left to do or should I close this?

[Antoine Martin]

Also use notifications for reporting failures in:

• r18250: webcam
• r18252: audio
• r18253: opengl
• r18259: desktop scaling