Creating it is quite heavy (25ms here) as it has to query NetworkManager for information.
Details
Details
- Reviewers
apol - Group Reviewers
Plasma - Maniphest Tasks
- T10958: Faster Startup
- Commits
- R134:89681ad47084: [Notifier] Delay creating QNetworkConfigurationManager
Diff Detail
Diff Detail
- Repository
- R134 Discover Software Store
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Yes, it's a big one.
I was wondering if it would make sense to see if we can improve it on Qt level.
| notifier/DiscoverNotifier.cpp | ||
|---|---|---|
| 166 | Explain why in a short comment. Something like // delay initializing, Qt does a bunch of blocking calls there when using networkmanager | |
Comment Actions
Is QNetworkAccessManager::networkAccessible any better?
It has an unknown state which implies it might be async.
Comment Actions
It's the constructor that takes forever, doesn't matter what I end up calling them but I can check more thoroughly.
Comment Actions
Sorry, misread you there. networkAccessible could work. It claims to reflect the actual device state and since the QQmlEngine already has its own QNetworkAccessManager we don't need to create one. I'll give it a go.
Comment Actions
As I feared, no matter if I disconnect, it's always NetworkAccessible, even with a stock QML app (i.e. without KIO AccessManager that KDeclarative injects).
QNetworkAccessManager only checks the actual network session when the QNetworkConfigurationManager::NetworkSessionRequired flag in the bearer plugin which isn't the case for us (only connman as far as I can tell). Otherwise it's merely a "did the caller disable network access explicitly or is it allowed".