As an author of D14931 I need to apologize for passing this bug and clear a thing about the 2nd case.
In the first version of the aforementioned patch (https://phabricator.kde.org/D14931?id=40016) I used raw pointers instead of QSharedPointer and was calling helper FilteredView::destroy() method in OutputWidget::removeOutput() in order not to store potentially big view and proxy model objects in memory when we don't need them anymore. This shouldn't cause double deletion because children object should remove itself from object hierarchy when being deleted (as far as I understand). Maybe you can use it too if you want.

@kossebau , @anthonyfieroni I've sumbitted the patch which should fix the bug: D15241. Hope that it's correct this time.

@anthonyfieroni, got it, thank you for answer. I'll try to submit the patch with fix today.

@anthonyfieroni, @kossebau, yes, that's definitely a bug. I didn't notice it, sorry for that. Should I fix it as a new commit to this patch or create a new patch?

Hi @kfunk, you've told that the patch looks good in general except for the redundant m_views.remove(id); call - I've deleted it. So what about the patch now? Should anything else be changed or can it be accepted now?

Hi @aaronpuchert, thank you for comment.
I was in doubt between these two variants while writing the code and stopped on current one for two reasons:

• Looking at QT source code, reset() is ultimately reduced to QSharedPointer copy(t); swap(copy); anyways. And QSharedPointer has move constructor, so it'll work in this case (right?).
• Current variant better expresses my intentions (that's subjective).

But if you still think that we should use reset() I'd change it in a moment. What do you think?

In D14931#314200, @kfunk wrote:

Thanks for your change even if you were not happy about it.

So what do you think? To me that is easier to follow, and gives very few chances for accidental leaks. One should use smart pointers more often these days.

Remove redundant m_views.remove()

Use QSharedPointers instead of raw pointers in FilteredView struct

Multiple improvements corresponding to review comments

Thanks a lot for the patch! Go ahead with refactoring this code in master branch, we'd appreciate it.

Thank you for the review :) I'll proceed to work on this soon.

Hi @kfunk. Sorry for being a little obtrusive, but I just wanted to clarify this a little. Should I wait for this ad hoc fix to be reviewed and accepted, or should I go directly to the refactoring and fix the bug on the way?

@brauch , sorry for mentioning you explicitly, just had a feeling that nobody has noticed the request for review :)

If these changes pass the review, I'd like to also make a little refactoring to this code consisting of using one QMap with structs containing pointers to corresponding view, filter and proxy model instead of 3 QMaps with the same keys in current code. Did I get it right that I should do these changes in separate patch?

I've tried to implement the approach discussed above. Here is the video of the results achieved as for now:

Implement automatic folder collapse and expand during drag'n'drop

Hi @kossebau , you're welcome. Thank you for testing my patch :)

I've removed redundant call to superclass method in ProjectTreeView::timerEvent, yet I don't quite think this could have been the reason of the flickering and, as for now, I can't find any other possible reason of the problem. Dear @croick, could you please tell me what OS do you use, so I can try running in VM and check if the flickering persists?

Remove redundant superclass method call

No, I don't. There where a few little twitches while I was testing it just now, but not the flickering. Here is the video of the test with patch applied.