<table><tr><td style="">davidedmundson 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/D22723">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Correctly as in "it's supposed to work" yes, but it's not as it was intended to be AFAICT.</p></blockquote>

<p>I've been going over ThreadWeaver.</p>

<p>The "decorator" is more of a wrapper, from what I can tell of ThreadWeaver we know the wrapper finishes, we know our wrapped object has finished.</p>

<p>I don't think ThreadWeaver API needs fixing. Merely Krunner's usage.</p>

<p>If we're using the QObjectDecorator pattern, RunnerManager is definitely meant to be starting the decorator and watching the wrapper not starting the underlying job.</p>

<p>That part is how it's meant to be.</p>

<hr class="remarkup-hr" />

<p><a href="https://phabricator.kde.org/p/fvogt/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@fvogt</a>'s new version<br />
Avoiding the relevant ThreadWeaver API is an equally a viable solution.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Or the job has to be moved to a different thread, which means that Qt makes the connection a queued one automatically.</p></blockquote>

<p>The job's thread is irrelevant. <br />
In evaluating AutoConnection Qt uses the current thread emitting the signal and the thread of the receiver, which in this case RunnerManager in the main thread. AutoConnect should be fine.</p>

<hr class="remarkup-hr" />

<p>IMHO the "most correct" approach would be for RunnerManager to not have the pointless QSets about that shadow the data the Queue already has.</p>

<p>Once we get there the QObjectDecorator object could be created purely within RunnerManager::startJob and ignored from there on.</p>

<hr class="remarkup-hr" />

<p>Both look fine to me, I would happily accept either. <br />
I don't want us to get blocked forever choosing which of two perfectly good options is the best.</p>

<p>If I did have to choose, I'd say I prefer Fabian's.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R308 KRunner</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D22723">https://phabricator.kde.org/D22723</a></div></div><br /><div><strong>To: </strong>apol, Frameworks, fvogt, davidedmundson<br /><strong>Cc: </strong>aacid, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns<br /></div>