slint-ui
Pipe image loading errors and similar error to the live-preview console
Feature Description
It's quite common to enter an image url incorrectly. These do result in errors but in VScode they are hidden away on the 'output' window where you also have to select 'slint' to see them. If they showed up in the live-preview console it would make the errors easier to deal with.
The next phase would be to show these errors in VScode in the same way other LSP linting errors show up. This would be a big help to generative AI agents that look at these errors to find and fix bugs in the code they generate. In recent experiments the agents in Cursor failed to understand image imports are relative to the file, not the project root. Seeing the image loading errors would have allowed it to easily self correct.
Product Impact
No response
Yes, we should totally have that.
This depends on https://github.com/slint-ui/slint/issues/3616 (although the title say it is for C++, it should be also done for Rust)
The global hook was also discussed also https://github.com/slint-ui/slint/pull/8609#discussion_r2123676947 (But it was dismissed at the time unfortunately)
Other things that would appear in the log:
- Invalid path
- "long changed callback chain detected"
- "Error loading custom font"
- invalid write to read-only model (although i don't know if that's possible in the preview)
- markdown parse error
One thing though is that it won't be possible to distinguish between error comming from the previewed application, or from the LSP view. For example, if, for some reason, we can't load an image used in our toolbar. It would also show in that console.
Another point is that we should ideally know the location in the .slint file where the path/image/mardown is so we can report the error with a proper location, so we'd need also to attach this information to the slint::Image / Path / StyledText for runtime diagnostic with location information. This could perhaps be conditioned on a feature flag or whether it is a debug or release build.
Also if we have these facilities we can also add debug output to layout when layout constraints can't be solved. But i'm getting carried away.
I wonder if wrong paths for @image-url() could be reported even earlier and not require going through a debug hook.
The next phase would be to show these errors in VScode in the same way other LSP linting errors show up.
Perhaps the LSP could re-use the EmbeddedResourcesKind::ListOnly mode and that way get an overview of all the image urls and produce diagnostics for those that aren't paths that point to existing files?
