<table><tr><td style="">dfaure added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D7380" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>It is rather hard to follow your reasoning...</p>

<ol class="remarkup-list">
<li class="remarkup-list-item">QtInfoMsg is *between* QtDebugMsg and QtWarningMsg, so it's *not* more verbose than QtDebugMsg, it's less. This is why our default setup (in the ECM macro) is to enable "info and up" (i.e. info, warning, critical) and not debug.</li>
</ol>

<ol class="remarkup-list" start="2">
<li class="remarkup-list-item">And QLoggingCategory::setFilterRules() has *nothing* to do with QSettings...</li>
</ol>

<p>Yes QSettings is persistent, but QLoggingCategory::setFilterRules() definitely isn't.</p>

<p>You're right about the first point though, qDebug() is associated to the "default" category of qCDebug(), so it's affected by *.debug=false, I hadn't realized that. Surely it must be the same for qInfo() then -- except that *.info=false would be a very stupid thing to do anyway, IMHO. One *wants* the output from command-line tools.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R342 KIO AudioCD</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D7380" rel="noreferrer">https://phabricator.kde.org/D7380</a></div></div><br /><div><strong>To: </strong>rjvbb, Frameworks, davidedmundson, ltoscano<br /><strong>Cc: </strong>dfaure, ltoscano, davidedmundson<br /></div>