The current 15 seconds timeout is really annoyingly long.
NetworkManager ignores/refuses most rescan requests when bashing the button,
that's the reason for the cooldown (preventing flooding NM via dbus).
I also took away the scanning event altogether since it had been removed anyways.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 7712 | |
| Build 7730: arc lint + arc unit |
| applet/contents/ui/Toolbar.qml | ||
|---|---|---|
| 124 | How about "Scan for new wireless networks"? | |
I don't think this should be added again, there is no reason to. Plasma-nm will do an initial scan once the applet is opened so you get the new networks immediately. This has been discussed with NetworkManager developers and everyone has to do now periodic scanning in some sane interval. Gnome does the some.
In my opinion, this sort of thing is a "help the user feel in control" issue. We had the same sort of conversations in Discover back when it didn't have a manual "refresh updates" button. People constantly complained and we had to explain over and over again that it automatically fetches when launched and periodically after that. Didn't matter; people wanted the button anyway, and periodically managed to get themselves into situations where Discover would get wedged and a button would actually be nice. Eventually we relented and added the button and now people are happy. I think the same thing may be going on here and user confidence in the software would benefit. People would feel more in control with a button they can click on when it's not doing what they expect or not finding their network fast enough.
I'm wrong, it actually doesn't perform scanning when the applet is opened. It should maybe be doing that, do initial scan on applet popup and then every 15 seconds only if you keep it opened.
Ignore, I was wrong that I was wrong, it does call RequestScan() when the applet is opened.
1000% this. Who cares about NM 😬 It really is about making it better for the user. I feel that already our 15 seconds timeout is ridiculously long.
I have made some tests with plasma-nm, and then looked in NM's code. It's an actual hard timeout of 10 whole seconds.
I don't really have a clue why would they ever have wanted to introduced this long a timeout. Any mobile device, or Windows, can do much faster than this crap.
So, anyways, counting the actual timeout plus whatever time your device takes to perform a scan, you can gain up to maybe 4 seconds by refreshing with the button.
A plus here: we'd be shifting the blame for updating wifis slowly to the actual responsible, networkmanager.
+1, it would be cool to have a button to scan for wireless networks. Today I tried to connect to Wi-Fi while having a wired connection activated, and no W-Fi networks were shown in plasma-nm applet. I had to use nmtui to connect to wireless net, so shame that plasma-nm lacks this functionality.
I will repeat myself, but this shouldn't be needed at all. If you open the applet, it immediately triggers new scan, which means that opening the applet and clicking on the rescan button will have zero effect, because there is some time you need to wait before you can request a new scan. It may take a while before your networks appear while the scan is being done.
But there are legit cases where this timeout is way too long for no reason.
If you close the popup and reopen it before the NM timeout expires, then the first request will fail, no attempt will be made at redoing the scan, and you're stuck for 30 seconds with the same list.
If your device takes 1 second for a full scan, you still have an useless wait of 5 more seconds before you can see the new wifi list.
All this while an user with a phone in their hand can already see updated wifi lists every 3-5 seconds, while the pc lags terribly behind. Honestly, if there was a way to configure away this 10s NM timeout, I would do it straight away. I'd also immediately try to add a configuration checkbox in the applet to disable it.
15 seconds.
Then you can fix this instead. You can check last scan attempt and make it to scan a bit later. There is a property in NM::WirelessDevice::LastScan, you can see when the last scan was performed and once the applet is opened, do a scan as soon as possible when you are sure the attempt will not fail.
no, if your device takes 2s for a scan, and if you open the popup, close it and reopen it (causing a new scan request) before the 12s mark, the popup will wait 15 more seconds, totalling ~27s. It was just an extreme example. Regardless, it's still a huge delay, if you consider that any phone will take ~2s for a scan but rescan every 3-4s when you have the wifi settings open.
Then you can fix this instead. You can check last scan attempt and make it to scan a bit later. There is a property in NM::WirelessDevice::LastScan, you can see when the last scan was performed and once the applet is opened, do a scan as soon as possible when you are sure the attempt will not fail.
I can find LastScan in the fd.o apidox, but not in NMQt... ?!?
If NM didn't have this timeout, we could have chosen ourselves how to do it (e.g. waiting for LastScan to be 5s in the past, then scan again). But it's now somewhat frustratingly slow, and a button could save a few seconds of annoyance that usually instead result in the user losing their patience and turning wifi off and on instead.
I know this whole proposal sounds silly.. for me this also is silly. This is however about improving the user experience in a few use cases, so I'm trying to mitigate it.
Again, I think this is a "the user doesn't feel in control" issue. If a feature of the software cannot automatically anticipate and meet user needs with 100% reliability, then the user must be provided with a method to self-serve for the cases where the software 's automatic behaviors are insufficient.
In theory, refreshing upon open and every 15 seconds after that should be sufficient. But if for some reason it's not, then without a refresh button, the user doesn't feel in control and loses confidence in your software, and then they get upset and start filing nitpicky bugs and complaining on Reddit.
Again, we went through the exact same thing in Discover. We made the same arguments. We explained the same things to our users. In the end we wound up giving them a button anyway and the complaints immediately stopped, as though flicking a switch.
I can find LastScan in the fd.o apidox, but not in NMQt... ?!?
It doesn't seem to be there. So lets add it.
I'll note that keeping the user feeling in control is one of the bullet points on the homepage of our HIG:
Always in control. - It should always be clear what can be done, what is currently happening, and what has just happened. The user should never feel at the mercy of the tool. Give the user the final say.
Not being able to manually refresh the list if and when you want to seems to me like an example of making the user feel at the mercy of the tool.
It's not there because it's most likely one of recent additions, which means we will not be able to rely on that if it's not in NM 1.4, or alternatively we will need to bump required NM version.
Then make it reliable. If it's realiable and as I mentioned there can be some improvements done, you will provide them a functionality which in most cases will give them just false feeling that they changed something. Nobody will need to wait 15 seconds, because scanning is done everytime you open the applet and browse your connections. I believe that majority of users will hit the button right after they open the applet, while there is scanning being done and they have the feel to hurry things up, while actually it will do nothing.
In theory, refreshing upon open and every 15 seconds after that should be sufficient. But if for some reason it's not, then without a refresh button, the user doesn't feel in control and loses confidence in your software, and then they get upset and start filing nitpicky bugs and complaining on Reddit.
I did receive just one bug for this and after I explained that this is done automatically on the background, the reporter didn't complain.
I don't want to keep adding things to a small applet to cover every single use case. I know it's just a small button, but next time it will be another button, search bar or anything else and the applet will become a monster as it used to be in KDE 4 times. When we were developing this applet back then with Björn and Thomas, the idea wasn't to make everyone happy, that's not really possible, but it shouldn't make anyone unhappy, which I think this really doesn't.
It's in 1.12.
If that's not an option, it wouldn't be the end of the world to re-request a scan on a 2 second timer in case Handler::replyFinished->Handler::RequestScan:
It'll just retry until it passes then go back to the 15s.
Indeed, it's only in 1.12, which is the latest one and we really cannot depend on that and guarantee it's available everywhere. I would go with this idea, you know when a scan request failed, you can try another one in 2 seconds.
Let me be clear here - I don't really care about having this change merged, or having to rewrite it into something wholly different. I just want everyone to have their list of wifi networks to be up to date when they need it, that is, when the nm applet is open.
If it means I have to instead go pester NetworkManager people for a configurable timeout or such, so be it - I just want to have a discussion to have a result that works.
That said, I think @jgrulich 's comment reliability doesn't hold much water, as we cannot really make it 'reliable': for now we can just spam NM with scan commands until we get a success.
We have a basic issue (the hard 10s timeout in NM) and there's nothing that anyone in KDE can do about it, save patching NM itself. So can we talk about its mitigation for now? Maybe not a button, maybe constantly trying to request scans until we get a positive answer? Anything will be better than having to stare for fifteen plus seconds at the nm applet until my damn tethering network finally appears in the applet and I can send my email.
I'll see about asking the NM devs about why is it so incredibly long and if it can be made configurable.
If it wil be made configurable, you wouldn't be still able to use it, without depending on newer NM version.
I don't see a big deal doing it this way:
This re-scan thing can be implemented in the replyFinished() signal where you know it failed. If in case 2 or 3 it successfuly made a scan, then we should reset the timer in the applet, otherwise you end up with 20+ seconds again.
I am abandoning this revision, since a button would be useless 95% of the time, thanks to NetworkManager.
I've submitted an automated retry mechanism (D18896). Later, I'd like to try adding some status icon showing when a new scan has been started, to let the user know something is happening.