File Watcher for Slint Editor

[LeonMatthes]

Add a file watcher to the Slint editor to detect changes in .slint
files.

Note that this will not correctly track resource files at the moment if
they are outside of the project directory.
We should wait until the remote viewer has implemented this in order to
unify it between all of the different file watcher implementations.

@ogoffart I think we should probably migrate the slint-viewer and built-in live
preview over to this as well. Then we can have a single source of truth
for extracting all file paths out of a type loader and watching them.
They currently use the open_imports_callback to detect file changes, but
that won't detect changes on resource files.
Moving it into the interpreter as a file_watcher module is best IMO.

[ogoffart]

@ogoffart I think we should probably migrate the slint-viewer and built-in live
preview over to this as well.

By builtin-live preview, you don't mean the live preview for Rust/C++, i guess.

Because there is also a file watcher in interpreter/live_preview.rs.

Why didn't you re-use that one?
Because yes, ideally, everything should use the same watcher.

(When I added the one in interpreter/live_preview.rs, i thought we could migrate the viewer to use it, but that never happened)

[LeonMatthes]

By builtin-live preview, you don't mean the live preview for Rust/C++, i guess.

I do mean that one.

Ah, crap, I hadn't noticed that this one already contains a separate FileWatcher abstraction 🙈
I'll check if we can use the existing one on Monday.
The general problem with using the import_callback is that it cannot detect resources files and doesn't let us know if we should ever unwatch files. I'll check if the old watcher deals correctly with paths & directories being created/moved, as notify seems to be a bit picky there if a path does not yet exist when trying to watch it.

But we shouldn't have a third file watcher in any case 😅

[LeonMatthes]

@ogoffart What do you think of the approach of watching the entire project directory?
IMO that should work pretty well, as we'll definitely get all updates and don't need to deal with re-watching deleted files, etc.
But we will also get additional unnecessary events that we need to filter out.
(The LSP already does this, but we could move it into the FileWatcher as well).

[ogoffart]

@ogoffart What do you think of the approach of watching the entire project directory?

I don't like it. This is what the LSP does:

slint/tools/lsp/language.rs

Line 130 in cd89140

glob_pattern: lsp_types::GlobPattern::String("**/*".to_string()),

And this is the reason why, i suspect, many apps stop working with "too many open file" when vscode is open, (because it would watch the entire monorepo of slint includeing the target directory or at least, too many files)

There are other way to detext dependencies on resources. The object_tree::Document::embedded_file_resources could have it if we pass the right flags to the CompilerConfig (EmbedResourcesKind::ListAllResources, I think this was added precisely for this usecase)
Another option is to use the resource_url_mapper.

Also there could be files outside of the project directory (eg, libraries in ~/.cargo/ or somewhere else). Arguably, these shouldn't change.

But it can also be hard to find the project root

[LeonMatthes]

@ogoffart What do you think of the approach of watching the entire project directory?

I don't like it. This is what the LSP does:

The new file watcher is not quite as aggressive, but it still watches the highest folder recursively that contains a loaded file.
I suspect we'll have to do some fixes to the FileWatcher then if we don't want to watch the project dir, so that deleted/renamed files and newly created directories work correctly.

There are other way to detext dependencies on resources. The object_tree::Document::embedded_file_resources could have it if we pass the right flags to the CompilerConfig (EmbedResourcesKind::ListAllResources, I think this was added precisely for this usecase) Another option is to use the resource_url_mapper.

Right, that is what the new FileWatcher basically does, it extracts a full list of file paths out of the TypeLoader.

So to combine the best of both approaches, we should extract the file watcher into its own module in the interpreter, use the new function from the typeloader to detect the files we need to watch and try to minimize the number of files we watch via notify. (we'll have to do some extensive testing on the file watcher for this).
I don't want to be back where we were with the live-preview a couple of weeks ago, where we had a bunch of subtle bugs with file updates.