changed the interaction for header view
both library and properties can be shown anytime
and selection is is a toggle button at any time
suggestions:
goes hand in hand with the selection mode
likely requires settings for toggle or single
select.
attempting a header change to optimize usability
TODO: make dragging from library automatically
into edit mode
the toggle that existed is the same as toggling a button - whcih can sit next to the closed library and properties.
properties should be editable while selection is active so those should be openable / visible whether in edit mode or not.
STILL TODO:
- make dragging from library automatically into edit mode
- add settings to either single select 'inspect' button or toggle on off
- change display of active icon OR add icon for toggled mode for clearer display than blue icon for inspect
The "tmpobj" variable was overwriten because the interpreter (contrary
to rust and C++) don't have scopes for the local variables, and local
variable of the same name would conflict.
(I think this could in theory be a problem in C++ and rust although i
haven't reproduced it)
Other uses of StoreLocalVariable also make the number unique with a
counter
Fixes#6721
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
Fixes#4356
Still not perfect:
- Calling several times `popup.show()` on the same popup, will open
that popup multiple times (instead of being a noop once opened)
- Calling `some-popup.close()` will always close the top of the stack,
without considering if it is the `some-popup` or another popup.
Both problems are because we don't remember whether a particular popup
is open and we don't associate `close()` with a particular popup
This currently doesn't have public API to enable it yet.
TODO:
- Error handling in the compiler
- Public API in the compiler configuration
- Documentation
Instead of cloning the vector on every iteration level, pass the
scope in and out of the visitation function and push/pop the element
there as needed. This way we can operate on a single vector that
gets moved around, which removes a few thousand memory allocations.
The speed impact is not measurable, as the code also triggers rowan
API that is much more allocation happy.
Still, I believe this patch is still merge-worthy as it also reduces
the code duplication a bit and is subjectively better, esp. from a
performance pov.
Instead of using the trick of taking a sub-slice and pretending the
image was smaller than it is.
Then this is more uniform with all the other rendering path.
And this should prevent the panic in #6643Fixes#6643
Instead of doing potentially multiple calls in the chained calls,
each of which would allocate in rowan, we now only call the iterator
function once and then leverage `find_map`. This is arguably even
more readable and it removes ~300k allocations and speeds up parsing.
Before:
```
Time (mean ± σ): 930.7 ms ± 15.1 ms [User: 678.7 ms, System: 165.5 ms]
Range (min … max): 906.4 ms … 956.3 ms 10 runs
allocations: 2339130
```
After:
```
Time (mean ± σ): 914.6 ms ± 22.7 ms [User: 649.6 ms, System: 174.5 ms]
Range (min … max): 874.8 ms … 946.3 ms 10 runs
allocations: 2017915
```
This is just for completeness, we "only" save ~13k allocations
with no measurable speed impact:
Before:
```
Time (mean ± σ): 1.019 s ± 0.033 s [User: 0.716 s, System: 0.203 s]
Range (min … max): 0.957 s … 1.061 s 10 runs
allocations: 2679001
```
After:
```
Time (mean ± σ): 1.015 s ± 0.015 s [User: 0.715 s, System: 0.201 s]
Range (min … max): 0.997 s … 1.038 s 10 runs
allocations: 2666889
```
Instead of occupying multiple TLS slots, introduce a single type
that stores all the builtin function types in members. Use a macro
to define this struct then, which allows us to use a nice DSL to
define these function types, reducing the boiler plate significantly.
The downside is that we no longer have the ability to easily share
semantically equivalent function types (e.g. for `Round`, `Ceil`
and `Floor` etc.). Doing so would require us to introdue a separate
name for these types, and then use external matching to map the
BuiltinFunctions to the reduced list of types. The performance impact
is minimal though, so this is not done to KISS.
This is rarely used, but using Rc here like elsewhere allows us to
elide a few unneccessary memory allocations when copying such types.
The speed impact is not measurable though. With heaptrack I see that
we get rid of the last ~7600 allocations in my benchmark when cloning
Type.
These are known statically, so let's store them once in thread local
statics and return them from there.
Before:
```
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
```
After:
```
Time (mean ± σ): 996.9 ms ± 17.7 ms [User: 708.9 ms, System: 202.9 ms]
Range (min … max): 977.8 ms … 1033.1 ms 10 runs
allocations: 2686677
```
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
```
This allows us to cheaply copy the langtype::Type values which
contain such a type. The runtime impact is small and barely noticable
but a sampling profiler shows a clear reduction in samples pointing
at langtype.rs, roughly reducing that from ~8.6% inclusive cost
down to 6.6% inclusive cost.
Furthermore, this allows us to share/intern common types.
Before:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 1.089 s ± 0.026 s [User: 0.771 s, System: 0.216 s]
Range (min … max): 1.046 s … 1.130 s 10 runs
allocations: 3152149
```
After:
```
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
```
