Fix slint-viewer --auto-reload for editors which rename and replace files

[0x6e]

Some editors may backup a file by renaming it to append ~, then saving the new file contents to a new file. notify-rs/notify#166 explains that a non-recursive watcher on the parent directory is the recommended way to deal with this situation.

Closes: #3641

[CLAassistant]

All committers have signed the CLA.

[ogoffart]

I think watching the parent directory is too much. If some random files is being created in that directory, we don't want to reload the view.
We only want to reload it if the created file is matching a name for which we depends.

[0x6e]

Tested manually using the attached files.
tests.tar.gz

It wasn't clear to me how best to test this in Rust. I could provide my own fswatch thread, but that would be testing that, rather than the existing thread.

[0x6e]

I think watching the parent directory is too much. If some random files is being created in that directory, we don't want to reload the view. We only want to reload it if the created file is matching a name for which we depends.

I had reservations about this too. I'll see what I can do.

[0x6e]

Updated test scripts:
tests.tar.gz

[ogoffart]

Looks good.
I added a few comments.

[0x6e]

I found that watching the parent directory wasn't sufficient for the first edit, but would work fine for subsequent edits. My test scripts essentially hid this problem. In hind-sight it is possible that this is due to PENDING_EVENTS being greater than zero when the parent dir event was triggered.

However, the new approach to retrying the watch is simpler, and works for all edits I make to the file.

[ogoffart]

I don't understand anymore how this works.
I wasn't aware that the watch command failled.

My understanding was that we were watching the file foo.slint
but the editor then renames foo.slint to foo.slint~ and since a rename is not a change in the file, the fswatcher don't see that change and continue watching the backup file instead of the new file.
I might have gotten details wrong. But i don't understand why this patch solves the problem.

[0x6e]

My understanding is as follows:

1. We watch the file foo.slint;
2. The editor renames foo.slint to foo.slint.swp;
3. notify sends a Modify(Name(Any)) event for the file, and removes the watcher (Explain how watch does not follow moves or renames notify-rs/notify#166 says removes explicitly, although the documentation is vague);
4. we attempt to reload foo.slint, but it doesn't exist so ComponentCompiler::build_from_path returns None;
5. The editor writes the new content to foo.slint;
6. We don't get any more events because nothing has re-watched the file.

This patch works because thanks to the retry, the events continue as follows:
7. The timer triggers and we attempt to watch foo.slint;
8. notify sends a Modify(Metadata(Any)) event for the file;
9. fswatcher thread triggers a reload, which is successful because slint.foo now exists.

As an alternative to the single shot timer, we could recursively watch the parent directory of slint.foo. We would need to maintain a set of files we care about, and fswatcher needs to make sure it sends events when watched files are re-added.

[ogoffart]

I see, thanks for the explanations.

@tronical , does it make sense to you?

[0x6e]

The risks of this patch are:

• the timeout is too short, in which case the file still won't exist and we never get a watch again;
• we don't receive a Modify(Metadata(Any)) event after watching the file, in which case we wouldn't reload until the next change.

Recursively watching the parent directory would avoid these issues, however it is not necessarily fool proof either. Notify has a number of known problems including reaching the max-files watch limit and failure to receive all events when watching very large directories.

[tronical]

Sounds like a reasonable workaround to me.

[ogoffart]

I'm a bit skeptical, but if you say this solves the problem, let's merge it.

[0x6e]

@ogoffart Would you like to see the watch parent approach?

[ogoffart]

I think it's fine as is, no need to overthink it. If the problem is solved this is good enough.