When using rust, allow panics to cross the boundaries of our vtable traits.
This avoids panic producing two backtrace with panic=unwind
This patch doesn't touch the ABI of out FFI interface, they stay extern "C", because
if a panic or exception crosses these boundaries, we are in trouble.
(Also, we have a panic=abort in our Cargo.toml anyway)
Previously to see errors or debug info using debug(...) required the output panel of a speperate IDE or for Slintpad to open the browser developer tools.
This PR adds a dedicated panel to the live-preview. Log messages include a link back to the source file and line number for fast finding where the message was generated. Syntax errors also now show in the logs.
By default the panel is minimised and logs will clear themselves on UI recompile. The last log message does show as a preview on the minimised bar meaning in many cases you never need to open the panel.
---------
Co-authored-by: Tobias Hunger <tobias.hunger@slint.dev>
This fixes the contents of the `n`-th repeater inside the
`ComponentContainer` to also show up in the `n`-th repeater *after*
the `ComponentContainer`.
The ComponentContainer is lowered to a Comonent Container and a
dynamic tree node. The tree node is managed manually and I messed
up the repeater indices since there were no entries in the repeater
array for the embedded components. That mad things hard to keep
consistent as components get merged.
This chnages that: It lowers a Component Container to Something like this:
```slint
ComponentContainer {
if false: Emtpy {}
}
```
This way the standard mechanismns make sure we have something to put into
the repeater list and that unscrews the indices, saving a bit of code along
the way.
The inserted repeated node is still marked as `is_component_placeholder`, so
that we can wire it up as needed.
`__1` is a valid identifier, which we normalized to
`--1`, which is invalid.
This changes the nromalization function to leave a `_` in the first position.
Because we set the viewport-width several time to different value during
the layouting of the ListView, it will cause this property to always be
dirty. In particular, this causes permanent restart of the fluent's
scrollbar animation on the size of the handle, causing continous
repaints.
Only the interpreter is implemented so far
MacOs won't work yet because we don't disable the default winit menubar
The viewer don't support removing the MenuBar yet
Fix test for #6984
Since global can cross-reference eachother, the Global storage need to
be a Rc of all global, and not a clone of the HashMap.
We need to hold it in a RefCell as new global are added during
initialization.
But then we can't take reference to the Rc<Global> anymore, so we need
to take a clone of it, meaning that the InstanceRef cannot be Copy.
SmolStr has an Arc internally for large strings. This allows
cheap copies of large strings, but we lose that ability
when we convert the SmolStr to a &str and then reconstruct a
SmolStr from that slice.
I was hoping for some larger gains here, considering the impact
of this code change, but it only removes ~50k allocations,
while the impact on the runtime is not noticeable at all.
Still, I believe this is the right thing to do.
Before:
```
allocations: 2338981
Time (mean ± σ): 988.3 ms ± 17.9 ms [User: 690.2 ms, System: 206.4 ms]
Range (min … max): 956.4 ms … 1016.3 ms 10 runs
```
After:
```
allocations: 2287723
Time (mean ± σ): 989.8 ms ± 23.2 ms [User: 699.2 ms, System: 197.6 ms]
Range (min … max): 945.3 ms … 1021.4 ms 10 runs
```
Popups are stored in a HashMap and are assigned an ID so popup.close(); closes the correct popup and so a single PopupWindow cannot be opened multiple times
This makes copying such types much cheaper and will allow us to
intern common struct types in the future too. This further
drops the sample cost for langtype.rs from ~6.6% down to 4.0%.
We are now also able to share/intern common struct types.
Before:
```
Time (mean ± σ): 1.073 s ± 0.021 s [User: 0.759 s, System: 0.215 s]
Range (min … max): 1.034 s … 1.105 s 10 runs
allocations: 3074261
```
After:
```
Time (mean ± σ): 1.034 s ± 0.026 s [User: 0.733 s, System: 0.201 s]
Range (min … max): 1.000 s … 1.078 s 10 runs
allocations: 2917476
```
Copying potentially thousands of properties for no reason is something
that can be easily optimized away to save a bit of time:
Before:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 1.108 s ± 0.015 s [User: 0.792 s, System: 0.231 s]
Range (min … max): 1.085 s … 1.133 s 10 runs
```
After:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 1.082 s ± 0.019 s [User: 0.773 s, System: 0.214 s]
Range (min … max): 1.054 s … 1.117 s 10 runs
```
This removes a lot of temporary allocations, note e.g. how this
was called once per component previously yet the data contained
in the map was always the same!
Before:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 636.2 ms ± 20.0 ms [User: 563.4 ms, System: 71.8 ms]
Range (min … max): 615.2 ms … 657.9 ms 10 runs
allocations: 3371939
```
After:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 600.6 ms ± 2.9 ms [User: 522.0 ms, System: 74.4 ms]
Range (min … max): 596.3 ms … 605.2 ms 10 runs
allocations: 2917930
```
This removes a lot of allocations and speeds up the compiler step
a bit. Sadly, this patch is very invasive as it touches a lot of
files. That said, each individual hunk is pretty trivial.
For a non-trivial real-world example, the impact is significant,
we get rid of ~29% of all allocations and improve the runtime by
about 4.8% (measured until the viewer loop would start).
Before:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 664.2 ms ± 6.7 ms [User: 589.2 ms, System: 74.0 ms]
Range (min … max): 659.0 ms … 682.4 ms 10 runs
allocations: 4886888
temporary allocations: 857508
```
After:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 639.5 ms ± 17.8 ms [User: 556.9 ms, System: 76.2 ms]
Range (min … max): 621.4 ms … 666.5 ms 10 runs
allocations: 3544318
temporary allocations: 495685
```
The origin of this proposal is the name of the `swipe-left`, etc.
directional, boolean properties. They're missing another verb in their
name. In principle the right choice would be "recognize". That is what
the type name suggests, that's the term the documentation uses, so the
code should read `recognize-swipe-left: true;`. However that is a long
word. "Handle" is a verb that's simpler. It's also more generic (that's
a downside), but it's otherwise short enough to make things look
"right":
```
SwipeGestureHandler {
handle-swipe-left: true;
swiped => { something.naviate-left(); }
}
```
Therefore this patch proposes to rename the type to SwipeGestureHandler
and prefixes the boolean directional properties with "handle".
Don't return an Option, just return 0 when the timer is not started.
As discussed in the API review, the rational is that the interval is
just like a field in a struct and when the struct is default
constructed, it is initialized to 0
