The change in https://github.com/slint-ui/slint/pull/6747
invalidated the cache, but it was only reloaded when one of the dependent was reloaded.
We need to reload the cache for all open file so that LSP feature continue to work on
open document even if they get no changes
* experiment for highlighting UX
this works really well but ideally goes back to what was selected before right click OR the selection actually moves rather than the hover color
* live-preview: Unselect in SelectionPopup again
When un-hovering some item to preview it's selection,
switch selection back to the original selection.
---------
Co-authored-by: Tobias Hunger <tobias.hunger@slint.dev>
* creating a lookup table of colors based on the set on apple docs
then selecting from these colors rather than always typing hex
also added an in property for setting selected color (future)
* splitting out method of changing selection colour for later
* forgot to pull CupertinoColors from import
* Squashed commit of the following:
commit 4924aa908d6e039a7bf1f79ede3dc7c26f71007f
Author: szecket <szecket@magrittescow.com>
Date: Fri Nov 15 17:31:45 2024 -0500
use defined Palette for states
commit 80711ee7188f37b1b29ce11855b6a636d7a39306
Author: szecket <szecket@magrittescow.com>
Date: Fri Nov 15 17:29:51 2024 -0500
make control colour consistent with style and other controls
commit 1cfd39e6da6643600e8b553dfab2418c8552cdc4
Author: szecket <szecket@magrittescow.com>
Date: Fri Nov 15 13:58:07 2024 -0500
selection of controls when focused is not current cupertino style and too strong
commit 4bf4ae6ad385e118687f752362b34e079c03fe22
Author: szecket <szecket@magrittescow.com>
Date: Fri Nov 15 13:42:58 2024 -0500
make foreground color contrast when selected
* removing property that is only in cupertino
... that provides a model containing all the elements
at a position sorted from "front" to "back" with extra
information so that we can present the data in a nice UI
in the next step.
The selection code now filters out builtins and ignore nodes
when collecting nodes. So the following filter step does not
need to take those into account anymore.
Whether a selection candidate is actually a part of the root
component or not is now handled by looking at whether the
elements text range is inside the root component's text
range. This is closer to what users expect to happen I think.
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
```
* spacing correction
* converted all property value blocks to widgets
* added secondary controls for color and string
* added secondary visuals to make hierarchy more visible
* live-preview: Wire up color widget with the backend
It lets you select colors based on the sliders, but it will
*only* apply the color when you hit enter on the text field
with the color string...
Not nice, but at least it does not keep losing state as it
round-trips the change through the code and compiler and
gets the state reset all the time.
* more dummy data
* cleanup of property sheet based on new controls
* added secondary visuals to make hierarchy more visible
correct extraneous changes
---------
Co-authored-by: Tobias Hunger <tobias.hunger@slint.dev>
Version 3.17 of the spec added a `position_encoding` field in the
ServerCapabilities, so use that.
Note that the spec says that UTF-16 is mendatory, and vscode only
support utf-16, meaning we currently have a bug when having non-ascii in
the source (#5669)
Unconfuse selecting something with a drop shadow. That is a
extra compiler-generated element that gets added before
the actual element we are looking for.
... by implementing it manually again :-/ And by
not using the EditorService that I thought was handling that.
And of course a TS map silently falls when your key is a Url,
so that needed fixing, too.
Fixes: #6706
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
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
```
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
```
