Bug 390959

Summary: Consider suppressing GUI display of non-fatal, non-user-actionable warnings
Product: [Applications] Discover Reporter: Nate Graham <nate>
Component: discoverAssignee: Aleix Pol <aleixpol>
Status: RESOLVED NOT A BUG    
Severity: normal Keywords: usability
Priority: NOR    
Version: 5.12.2   
Target Milestone: ---   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=388101
https://bugs.kde.org/show_bug.cgi?id=390217
https://bugs.kde.org/show_bug.cgi?id=390922
https://bugs.kde.org/show_bug.cgi?id=390425
https://bugs.kde.org/show_bug.cgi?id=388076
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Nate Graham 2018-02-23 16:31:30 UTC
Discover is very "chatty" in that it displays a lot of GUI PassiveNotifications regarding its internal state.

This can be important for fatal errors that require intervention, but for non-fatal errors and warnings, they don't actually help the user because they're generally not actionable unless you are a developer, and that's not Discover's primary target audience (see https://community.kde.org/KDE_Visual_Design_Group/Muon_Discover#Personas). Displaying non-actionable status information reduces the user's confidence in a program's ability to manage its own affairs, and makes it seem needy and fragile.

I'm thinking specifically about the following common messages:
- Invalid knsrc messages (Bug 388101 and Bug 390922)
- Non-fatal Flatpak warnings when the requested operation succeeds anyway (Bug 390217 and Bug 390425)
- Redundant message after cancelling password prompt (Bug: 388076)

These messages may be actionable for developers, but they are confusing and frightening for users. I propose that we make these messages log to the console and don't display them in the GUI.


Benefit for users:
- Increased confidence in Discover

Benefit for developers:
- A whole class of bug reports and user frustration issues disappears
Comment 1 Aleix Pol 2018-02-26 13:37:53 UTC
This bug report is not actionnable.

Sure, let's not show spurious error messages.
We must remember to not skip the ones where we're being told our system is broken.
Comment 2 Nate Graham 2018-02-26 13:39:41 UTC
Ok, let's suppress useless, non-actionable error messages on a case-by-case basis, then.
Comment 3 Nate Graham 2018-06-27 21:27:08 UTC
One such case: Bug 395937.