D12527: Remove reimplementation of PartDocument:close() in TextDocument

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D12527#300264 <https://phabricator.kde.org/D12527#300264>, @croick wrote:
  
  > I was just discovering the same. `QTest` doesn't do DeferredDeletes (QTBUG-12575 <https://bugreports.qt.io/browse/QTBUG-12575>), so adding
  >  `QCoreApplication::sendPostedEvents(0, QEvent::DeferredDelete);`
  >  as suggested in the bug report would fix the test.
  
  
  That bug report though is about running the event handler on exiting the test, no?
  
  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 `Document::close()` being called, but now no longer is:
  
    // 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
    }
  
  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 `Sublime::DocumentPrivate::removeView(...)` 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.
  
  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.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D12527

To: croick, #kdevelop, kossebau
Cc: kossebau, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180730/813c3375/attachment.html>