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