GNOME Bugzilla – Bug 687853
Missing information about mobile access technology and roaming status
Last modified: 2021-07-05 14:41:31 UTC
Previously network-manager-applet would also show the current access technology (e.g. LTE or EV-DO or HSPA+) as well as the roaming status (either if roaming or not). This information is now not given in the gnome-shell network indicator, which shows only the "Operator Name" and "Signal Quality" of the current mobile broadband network in which the device is registered. Not sure about the access technology, but I would definitely include the roaming status in the indicator somehow. One option would be to include this information as text between the operator name and signal quality, like: "Movistar (roaming) (hspa+) <signalquality>" Another option would be to use another icon for the signal quality when in roaming; e.g. with an "R" letter somewhere, or something...
Created attachment 231793 [details] nm-applet For reference, a screenshot of nm-applet showing the information about access technology in 2 places: * In the icon itself (the little 'H' stands for HSPA) * In the menu item, along with the operator name and connection profile name
Created attachment 232288 [details] [review] NetworkMenu: show access technology togheter with signal for wwan devices Use an emblemed icon in place of the old signal icon, to show both signal and access technology (gprs, umts, 3g or 4g) next to the operator name.
Created attachment 232289 [details] [review] NetworkMenu: show a 3G signal icon in the panel when connected Even if the 3G connection is not the default, show a 3G icon in the panel between wifi and vpn. The active connection and icon code has been refactored to more closely represent the design, which is to show wifi, 3g and vpn individually when present, and only show wired when nothing better is present.
These patches only address the access technology, and only when a connection is active. What we really want is to show the wwan icon when the modem is enabled/registered, even if not connected, but that's blocked on enabling modems at startup and having NM expose useful modem state to us.
(In reply to comment #4) > These patches only address the access technology, and only when a connection is > active. Wanted to test the patches but I cannot really apply them properly. Are they rebased on top of git master or some other branch I don't know of?
They are on top of bug 676345, bug 676758, bug 684279, bug 683288 and bug 658230. Time to land some of those, I guess...
(In reply to comment #6) > They are on top of bug 676345, bug 676758, bug 684279, bug 683288 and bug > 658230. > Time to land some of those, I guess... Not one of the patches in the unfixed bugs applies cleanly right now. Would you be able to rebase so I can test this patch? Thanks.
Created attachment 236295 [details] [review] NetworkMenu: show access technology togheter with signal for wwan devices Use an emblemed icon in place of the old signal icon, to show both signal and access technology (gprs, umts, 3g or 4g) next to the operator name.
Created attachment 236296 [details] [review] NetworkMenu: show a 3G signal icon in the panel when connected Even if the 3G connection is not the default, show a 3G icon in the panel between wifi and vpn. The active connection and icon code has been refactored to more closely represent the design, which is to show wifi, 3g and vpn individually when present, and only show wired when nothing better is present.
Review of attachment 236295 [details] [review]: Not a full review, just spotted "togheter"
Giovanni's patches solve the problem I had in bug 693899. I had to add the following snippet though, otherwise it would get this error: JS ERROR: !!! Exception was: TypeError: connection is null JS ERROR: !!! message = '"connection is null"' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/status/network.js"' JS ERROR: !!! lineNumber = '2145' JS ERROR: !!! stack = '"(null)@/usr/share/gnome-shell/js/ui/status/network.js:2145 Dan, you've added that code, is that a problem, or am I just papering over the cracks. diff --git a/js/ui/status/network.js b/js/ui/status/network.js index 228ddc7..b991bbf 100644 --- a/js/ui/status/network.js +++ b/js/ui/status/network.js @@ -2000,7 +2000,7 @@ const NMApplet = new Lang.Class({ // Ignore slave connections let connectionPath = activeConnections[i].connection; let connection = this._settings.get_connection_by_path(connectionPath) - if (this._ignoreConnection(connection)) + if (!connection || this._ignoreConnection(connection)) continue; supportedConnections.push(activeConnections[i]);
*** Bug 693899 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Dan, you've added that code, is that a problem, or am I just papering over the > cracks. Hm... do you have a connection active that the logged-in user doesn't have permission to see? Otherwise I can't see how you could get null there... (except maybe in a race condition that would only apply if you had just created and immediately activated a connection). Any warnings from libnm-glib before the JS error? Anyway, I guess the two cases about could happen sometime, so checking for null there probably makes sense. But if neither of those cases apply to you, then yeah, that might mean there's a bug somewhere else that you'd be papering over.
(In reply to comment #13) > (In reply to comment #11) > > Dan, you've added that code, is that a problem, or am I just papering over the > > cracks. > > Hm... do you have a connection active that the logged-in user doesn't have > permission to see? A VPN and a Wi-Fi connection, both started by the same user running the shell. > Otherwise I can't see how you could get null there... > (except maybe in a race condition that would only apply if you had just created > and immediately activated a connection). The connections were already made, I simply restarted gnome-shell to test the patches. > Any warnings from libnm-glib before the JS error? No warnings, other than nm-applet saying it was now "embedded" (though obviously hidden). > Anyway, I guess the two cases about could happen sometime, so checking for null > there probably makes sense. But if neither of those cases apply to you, then > yeah, that might mean there's a bug somewhere else that you'd be papering over. I guess I should check if connectionPath is non-null too.
Can we land this for GNOME 3.10?
(In reply to comment #15) > Can we land this for GNOME 3.10? Yes, but the patches still need review, and we'll probably only branch after 3.8.1 ...
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.