<table><tr><td style="">davidedmundson marked an inline comment as done.<br />davidedmundson added inline comments.
</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/D13034">View Revision</a></tr></table><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D13034#inline-82523">View Inline</a><span style="color: #4b4d51; font-weight: bold;">dfaure</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kconfigtest.cpp:1800</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">typo: mimics</p>

<p style="padding: 0; margin: 8px;">The fact that it's not actually another process, means that this test would pass with a simple emit as well ;)<br />
A proper test would use QProcess to run a helper executable which would make changes to a config file.</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">Fixed the typo</p>

<p style="padding: 0; margin: 8px;">Any test would still pass if you had explicit code that cheated to make tests pass!</p>

<p style="padding: 0; margin: 8px;">I want to add "--notify" support in kwriteconfig5. That currently lacks any tests, I can do that which would cover proving that this is sending it properly, whilst keeping this more advanced test still readable.</p></div></div><br /><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D13034#inline-82525">View Inline</a><span style="color: #4b4d51; font-weight: bold;">dfaure</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kconfig.cpp:465</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">I wonder if we should skip doing this work when DBUS support is disabled, for performance reasons.<br />
More #if, but more speed... in the corner-case scenario though.<br />
So I'm not sure ;)</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">We still have the loop regardless.</p>

<p style="padding: 0; margin: 8px;">It doesn't make sense for apps to use notify if they're running in a standalone environment.<br />
So practically I think we'd only save an if statement on a flag.</p></div></div><br /><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D13034#inline-82526">View Inline</a><span style="color: #4b4d51; font-weight: bold;">dfaure</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kconfigbase.h:62</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">Let's go for 51 :)</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">Sure, I'll change this when I merge.</p>

<p style="padding: 0; margin: 8px;">Typing <span class="phabricator-remarkup-mention-unknown">@since</span> like this is the only strategy that hasn't caused headcaches with the fastpaced frameworks cycle. It's easier to grep for than a number.</p></div></div><br /><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D13034#inline-82533">View Inline</a><span style="color: #4b4d51; font-weight: bold;">dfaure</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kconfigwatcher.cpp:20</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">(I'm curious, why not a raw pointer? You clean up the hash when the watcher is destroyed anyway; probably doesn't matter either way though)</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">I'm returning QSharedPointers to the caller.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R237 KConfig</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D13034">https://phabricator.kde.org/D13034</a></div></div><br /><div><strong>To: </strong>davidedmundson, broulik, dfaure<br /><strong>Cc: </strong>dfaure, broulik, zzag, kde-frameworks-devel, michaelh, ngraham, bruns<br /></div>