D28770: Avoid blocking the UI thread
Kai Uwe Broulik
noreply at phabricator.kde.org
Mon Apr 13 10:06:05 BST 2020
broulik added a comment.
I don't fully understand the need for a thread here.
It merely blocks because the API is synchronous and thus we create a nested eventloop.
I don't think the writing and parsing of the cache file is a real bottleneck here.
INLINE COMMENTS
> currency.cpp:57
> +
> + for (const QNetworkInterface &net : QNetworkInterface::allInterfaces()) {
> + if (!net.flags().testFlag(QNetworkInterface::IsUp)) {
Can probably just use `QNetworkConfigurationManager::isOnline()`?
> currency.cpp:124
> +
> + static QNetworkAccessManager m_netAccessManager;
> +
Use prefix `s_` since it's static
> currency.cpp:154
> + }
> + m_reply = m_netAccessManager.get(QNetworkRequest(QUrl(QString::fromLatin1(URL))));
> + connect(m_reply, &QNetworkReply::finished, this, &CurrencyCacheUpdater::onReplyFinished);
Whenever you do networking in KDE, ensure it follows redirects:
`setRedirectPolicy(QNetworkRequest::NoLessSafeRedirectPolicy)` I guess
REPOSITORY
R292 KUnitConversion
REVISION DETAIL
https://phabricator.kde.org/D28770
To: sandsmark, ngraham, #frameworks, broulik
Cc: broulik, ngraham, kde-frameworks-devel, #frameworks, LeGast00n, cblack, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200413/47f8a175/attachment.html>
More information about the Kde-frameworks-devel
mailing list