- User Since
- Aug 5 2018, 4:33 PM (41 w, 2 d)
Sep 8 2018
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.
Sep 3 2018
@anthonyfieroni, got it, thank you for answer. I'll try to submit the patch with fix today.
Sep 2 2018
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?
Aug 24 2018
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?
Aug 23 2018
Remove redundant m_views.remove()
Use QSharedPointers instead of raw pointers in FilteredView struct
Aug 19 2018
Multiple improvements corresponding to review comments
Aug 16 2018
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?
Aug 15 2018
Aug 14 2018
@brauch , sorry for mentioning you explicitly, just had a feeling that nobody has noticed the request for review :)
Aug 12 2018
Aug 11 2018
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
Aug 6 2018
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
Aug 5 2018
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.