Testing: compile times, CI, contributions (& +ve feedback)

[MusicalNinjaDad]

Hi,
First off - thank you for creating Slint! I've always avoided creating an app, and stuck to libs, as I couldn't even work out what to search for to find a good UI framework. Slint's declarative style is exactly what I've been missing all this time.

Second - thank you again, for the approach you've taken in the WIP/internal testing crate! Using the accessibility functionality is not only genius from a testing API PoV, it has also ensured I code in accessibility from the start!

Please keep the accessibility approach!

1. I noticed my compile times go up significantly once I introduced slint.
   Adding a blank line somewhere and re-running cargo test went from an already hefty 10s build before Slint to 20s with Slint (Times are for compiling only my crate, all deps already compiled, incremental)
   Is this "normal" or am I missing a configuration or setting that could help optimise this?

2. I found that running tests in CI (github actions) failed with:

   error: couldn't read `/home/runner/work/HelixFlow/HelixFlow/target/debug/build/SLINT_DEFAULT_STYLE.txt`: No such file or directory (os error 2)
     --> src/ui/slint.rs:3:1
      |
   3  | / slint! {
   4  | |     import { Button, LineEdit, VerticalBox } from "std-widgets.slint";
   5  | |     export component HelixFlow inherits Window {
   6  | |         callback create_task;
   ...  |
   23 | | }
      | |_^
      |
      = note: this error originates in the macro `::core::include_bytes` (in Nightly builds, run with -Z macro-backtrace for more info)
   

   I hacked a fix via git add --force target/debug/build/SLINT_DEFAULT_STYLE.txt; but I'm guessing there's a better way(?)
   (Immeditealty after posting this - I ran another clean build and noticed when this file is created... Could it be that swatinem/rust-cache doesn't cache the file, but having that cache in place means it's not recreated when cargo test or cargo clippy run?)

3. Would you be open to contributions to i-slint-backend-testing - either code or documentation - if I spot anything that may help make it less internal and more a core part of the USP?

Thanks!

[ogoffart]

1. I noticed my compile times go up significantly once I introduced slint.

Yes, there is an issue about that. #4082
Things have improved a bit since then, but it is still slow to compile Rust. I think it is because we generate struct with lots of fields, and the compiler don't like that.

2. I found that running tests in CI (github actions) failed

This is very strange, this file should be written by the i_slint_backend_selector's built.rs
It really should exist.

3. Would you be open to contributions to i-slint-backend-testing - either code or documentation - if I spot anything that may help make it less internal and more a core part of the USP?

Sure, any help is welcome. Although at this point I don't think we're ready yet to commit to stability of this API, but maybe in the future.

[MusicalNinjaDad]

Thanks for the fast feedback ... I've played around a lot more and:

1. I've split my "app that does nothing (yet)" into 4 crates (ui, core, backend & app) - coupled with nextest that's got me a fast-enough feedback loop

2. I've tracked this down to swatinem/rust-cache which doesn't cache the file, but does cache the rest of slint. I'll open an issue later for tracking (or won't do / doc only / ...)

3. That's great. I'm not worried about the API changing over time, but I can see a few opportunities to make life easier for people to use it outside the API itself ...

[MusicalNinjaDad]

Issue: #8445