Unfortunately I don't have this area studied enough yet to consult the direction. But I certainly can test your code and report issues:). So far I found some regarding refreshing:

• external changes aren't reflected (I have to manual refresh Ctrl+R to see them)
• undo action will not refresh view after it is done

But I understand it is a work in progress, so please say if it is too soon to test these "corner" cases. Anyway, thanks for Your work!

In D3994#76189, @martinkostolny wrote:

Unfortunately I don't have this area studied enough yet to consult the direction. But I certainly can test your code and report issues:). So far I found some regarding refreshing:

• external changes aren't reflected (I have to manual refresh Ctrl+R to see them)
• undo action will not refresh view after it is done
  
  But I understand it is a work in progress, so please say if it is too soon to test these "corner" cases. Anyway, thanks for Your work!

Thanks for testing :)
Yes it's a bit early for these kinds of tests - also the new startRefresh() method isn't yet called anywhere.
I temporarily disabled using default_vfs::refreshLocal() for local paths - that's why you don't get automatic updates.

Please don't restrict the reviews!

I'm actually unsure if there is any benefit for a "real" async refresh. The panel currently depends on it and the Qt event loop prevents an UI freeze during a long refresh.

In D3994#77448, @abika wrote:

I'm actually unsure if there is any benefit for a "real" async refresh. The panel currently depends on it and the Qt event loop prevents an UI freeze during a long refresh.

The thing with temporary event loops is: they don't nest well. You have a long refresh spinning an event loop. Now what if one of the events being processed does the same and spins an event loop of its own for a while? The refresh won't be done until that second event loop is finished. And if the two actions deadlock each other you will keep spinning these event loops forever.