Bug 399973 - Don't show a popup notification when a network connection is activated on login (after that is fine though)
Summary: Don't show a popup notification when a network connection is activated on log...
Status: RESOLVED FIXED
Alias: None
Product: plasma-nm
Classification: Unclassified
Component: applet (show other bugs)
Version: 5.13.5
Platform: Other Linux
: HI wishlist with 40 votes (vote)
Target Milestone: ---
Assignee: Jan Grulich
URL:
Keywords: usability
: 375045 448440 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-18 08:10 UTC by Tyson Tan
Modified: 2022-04-10 16:05 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24.2


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tyson Tan 2018-10-18 08:10:08 UTC
SUMMARY
Right now Plasma shows a popup notification when a network connection is activated. This is not only limited to NEW connections, but also KNOWN connections. 

I think we only need notifications when news happens or something is broken. We probably don't need to be reminded every time upon log in that our Wired Ethernet connection is working perfectly as usual. 

I think such notifications has little meaning and they are distracting nuisances. I don't remember this happening on any other systems I used either. Please allow me to suggest we consider not showing a popup message for an "Connection activated" event by default.

Yes I know we can disable it by quickly clicking on the 2nd right-most icon:
[ ] Show a message in a popup

But I think it's not that straight forward for a new user to figure out.
Comment 1 Kai Uwe Broulik 2018-10-18 08:33:01 UTC
It makes sense to have it when you manually click connect (or does it, given the status changes right in the plasmoid) but it definitely shouldn't show it every time you log in.
Comment 2 Nate Graham 2018-10-18 19:57:03 UTC
Agreed, no need to show a connection notification on login--only after that.
Comment 3 Patrick Silva 2019-01-23 12:55:49 UTC
*** Bug 375045 has been marked as a duplicate of this bug. ***
Comment 4 Claudius Ellsel 2020-06-11 23:48:34 UTC
I did some search and I guess this is the corresponding function needing adjustments, correct? https://phabricator.kde.org/source/plasma-nm/browse/master/kded/notification.cpp$371
Comment 5 Nate Graham 2020-06-12 16:22:55 UTC
Yes, that would need to check for whether the user just clicked the "Disconnect" button to produce the action that changed state and generated a notification, and if so, don't send the notification.
Comment 6 Claudius Ellsel 2020-06-12 19:36:24 UTC
I guess you meant "only show a notification if the user pressed connect button before"?

I am not sure whether there are other ways how a connection could get established where a notification might be wanted.

I guess more foolproof would be to somehow detect whether it was activated (automatically) right after login. Unfortunately I don't know how that can be achieved.
Comment 7 Nate Graham 2022-01-14 21:07:43 UTC
*** Bug 448440 has been marked as a duplicate of this bug. ***
Comment 8 Bug Janitor Service 2022-02-19 15:22:17 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-nm/-/merge_requests/105
Comment 9 Fushan Wen 2022-02-20 10:13:57 UTC
Git commit bd5078d8a5d6dea351339641ab8be3a392039ce8 by Fushan Wen, on behalf of Nate Graham.
Committed on 20/02/2022 at 02:59.
Pushed by fusionfuture into branch 'master'.

kded: don't show "connection activated" notifications on launch/login

The daemon connects to NetworkManager::ActiveConnection::stateChanged
signals to show notifications, and this signal gets emitted when the
daemon launches to first make its connection. As a result, every time
the user logs in or the plasma-nm kded module is restarted (manually or
due to a crash), a "Connection activated" notification is shown. This is
annoying and redundant since the connection was made with no user action
taken; the user *expects* background processes to work normally and does
not need to be explicitly notified of it.

Plasma-nm already has some logic to suppress these notifications that
would be sent within the first 10 seconds after waking up from sleep,
but it does not handle the case of the same thing happening right when
the daemon is launched (e.g. on login).

This commit makes it handle that use case as well, with the same
approach: suppressing "activated" notifications sent within the first 10
seconds.
FIXED-IN: 5.24.2

M  +15   -0    kded/notification.cpp
M  +1    -0    kded/notification.h

https://invent.kde.org/plasma/plasma-nm/commit/bd5078d8a5d6dea351339641ab8be3a392039ce8
Comment 10 Fushan Wen 2022-02-20 10:14:27 UTC
Git commit 622f53da6184dc90d5834a9e75fb1cb1c3af5986 by Fushan Wen, on behalf of Nate Graham.
Committed on 20/02/2022 at 10:14.
Pushed by fusionfuture into branch 'Plasma/5.24'.

kded: don't show "connection activated" notifications on launch/login

The daemon connects to NetworkManager::ActiveConnection::stateChanged
signals to show notifications, and this signal gets emitted when the
daemon launches to first make its connection. As a result, every time
the user logs in or the plasma-nm kded module is restarted (manually or
due to a crash), a "Connection activated" notification is shown. This is
annoying and redundant since the connection was made with no user action
taken; the user *expects* background processes to work normally and does
not need to be explicitly notified of it.

Plasma-nm already has some logic to suppress these notifications that
would be sent within the first 10 seconds after waking up from sleep,
but it does not handle the case of the same thing happening right when
the daemon is launched (e.g. on login).

This commit makes it handle that use case as well, with the same
approach: suppressing "activated" notifications sent within the first 10
seconds.
FIXED-IN: 5.24.2


(cherry picked from commit bd5078d8a5d6dea351339641ab8be3a392039ce8)

M  +15   -0    kded/notification.cpp
M  +1    -0    kded/notification.h

https://invent.kde.org/plasma/plasma-nm/commit/622f53da6184dc90d5834a9e75fb1cb1c3af5986
Comment 11 Tyson Tan 2022-02-20 10:22:06 UTC
Thank you, guys!