<table><tr><td style="">kossebau 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/D12527">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D12527#300264" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: line-through;">D12527#300264</a>, <a href="https://phabricator.kde.org/p/croick/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@croick</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>I was just discovering the same. <tt style="background: #ebebeb; font-size: 13px;">QTest</tt> doesn't do DeferredDeletes (<a href="https://bugreports.qt.io/browse/QTBUG-12575" class="remarkup-link" target="_blank" rel="noreferrer">QTBUG-12575</a>), so adding<br />
 <tt style="background: #ebebeb; font-size: 13px;">QCoreApplication::sendPostedEvents(0, QEvent::DeferredDelete);</tt><br />
 as suggested in the bug report would fix the test.</p></div>
</blockquote>

<p>That bug report though is about running the event handler on exiting the test, no?</p>

<p>While here we are running into the issue that the test case uncovers that before something was by chance running the DeferredDelete event handler as a result of <tt style="background: #ebebeb; font-size: 13px;">Document::close()</tt> being called, but now no longer is:</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">// Test that both the view and the view widget is deleted when closing
// document.
{
    IDocumentController *documentController = Core::self()->documentController();
    documentController->openDocumentFromText(QStringLiteral("Test1"));
    Sublime::Area *area = Core::self()->uiControllerInternal()->activeArea();
    QCOMPARE(area->views().count(), 1);
    QPointer<Sublime::View> the_view = area->views().at(0);
    QPointer<QWidget> the_widget = the_view->widget();
    documentController->openDocuments().at(0)->close(IDocument::Discard);
    // as result of that ^ call before something was triggering the DeferredDelete handler, but now no longer is
    QCOMPARE(the_view.data(), (Sublime::View*)nullptr);
    QCOMPARE(the_widget.data(), (QWidget*)nullptr); // <-- now fails
}</pre></div>

<p>By looking at the code I guess this is due to something in the destruction of KTextEditor::Document. Which with the new code only happens in a deferred delete handler as well, as the final destruction of the KDevelop document only is triggered by <tt style="background: #ebebeb; font-size: 13px;">Sublime::DocumentPrivate::removeView(...)</tt> on closing the last view via deleteLater, which is triggered by the closeViews() as called from PartDocument::close(). While the old code did an instant deletion of KTextEditor::Document already in the TextDocument::close() call.</p>

<p>Meh. All the document/view destruction seems partially out of control *insert image of destructed-by-explosion tower falling in wrong direction*. Time to regain control. Will poke around that logic some more and try to come up with some sublime design policies for document & view, like who owns what, in which threads do they live and who is responsible for creation & destruction.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D12527">https://phabricator.kde.org/D12527</a></div></div><br /><div><strong>To: </strong>croick, KDevelop, kossebau<br /><strong>Cc: </strong>kossebau, kdevelop-devel<br /></div>