Fixed lost editor when file is updating and the list model to correctly handle next item
ClosedPublic

Authored by nmel on Jul 13 2019, 6:58 AM.

Details

Summary

The lost editor issue (see the bug for reference) was happening
because the editor hasn't been closed in the view but the item is
deleted and re-inserted. The fix is to close any editor attached to
an item before removing the item.

The workaround for next item current selection introduced in 2fbd49f0
is no longer needed due to the fix of the underlying issue in the list model.
Without the fix, the lost editor issue is also observed
when editing the file which is next to the updating one.

FIXED: [ 392750 ] After trying to rename the file that's being updated, rename function stops working on any file on this tab
BUG: 392750

Test Plan

Try to rename various files when other files in the dir are updating.
Pay attention on current selection, file selection and whether editing is triggering and if it's resetting only in case the file is updating.
See the bug for details.

Handy command to have an updating file:
$ for ((i = 0; i < 1000; i++)); do touch file.txt; sleep 1; done

Diff Detail

Repository
R167 Krusader
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
nmel requested review of this revision.Jul 13 2019, 6:58 AM
nmel created this revision.
gengisdave accepted this revision as: gengisdave.Jul 13 2019, 9:52 AM
gengisdave added a subscriber: gengisdave.

Tested on Fedora 30; it compiles and the bug is not present anymore; during the same test, a Krusader version without this patch was having this problem while the patched one was able to rename the file.

If I try to rename even the updating file, the editor closes but I'm able to edit it again.

This revision is now accepted and ready to land.Jul 13 2019, 9:52 AM
This revision was automatically updated to reflect the committed changes.
nmel added a comment.Jul 20 2019, 6:20 AM

Thanks for checking, Davide! :)