Add a filter into the Selection popup to filter out
anything not matching.
If all letters are lowercase, then it will do a case-insensitive
match, if there are non-lowercase characters it will do
case-sensitive matching instead.
Have the selection popup actually highlight the hovered
object in the editor.
We did not have this use case before: We used to either
highlight after an update or never at all. Neither semantic
matches what we are doing in the selection popup, so I added
a highlight-now flag.
* 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>
... 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.
* 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>
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
```
Filter out properties related to layouts that make no sense
for the current element. These are x/y coordinates and the
grid layout related properties.
It's tricky to do: The properties are looked up in the
context of the unoptimized DocumentCache, so that
(most) properties are visible. The layout information is
not available there though as base types are not resolved yet.
So the layout information is taken from the preview data.
All other tools have custom widgets for x/y, width/height, etc.,
let's try to come close by at least presenting the properties in
in a logical order that lends itself to data input.
This reorders geometry to show `x`, `y`, `width` and `height` followed by `z`.
It also orders layout as `min-width`, `min-height`, `preferred-width/-height',
and `max-width/height` followed by horizontal and vertical stretch.
I was stupid this morning: The properties need to be sorted.
So I need to group the properties into groups and I also want
to be able to define in which order the groups will be listed
in the UI. So add a `priority` in addition to the group and use
group name and priority to sort properties into groups.
The test changes since the order changed and it tries to insert
based on previous/later properties.
When no bindings exist on the component, the value that is shown in the
property editor should be the default value for that property as defined
in the base component or in the builtin element. Not just the default
value of the type
Move the model into an extra porperty and move information
irrelevant for the UI behind a callback, so that changing that info
will not invalidate the UI.
... and make `Ctrl-Shift-R` trigger it in edit mode, in the same broken
way we handle the `Delete` key. It works -- till you hit `Tab` to move
the focus.
We really need #4063 or similar!
I got carried away, I replaced `u32` with `TextSize` in one place
because that's what I got and I did not want to convert... and
then I fixed the fallout.
No functional change is intended in any of this.
FIXUP
Pass the syntax node defining the current property value along with
the other information on properties.
This will allow us to look at the AST nodes and not just the string
value containing the expression.
The Properties are no longer sent out straight to the editor, so
we do not need to convert our internal `TextRange` and `TextSize`
to `lsp_types::Range` and `lsp_types::Position`.
We are noweadys turning that straight back into offsets -- which is
just another name for `TextSize` (or pairs of offsets).
These commands are not needed anymore since we integrated
the property editor into the live preview.
Move the properties code out of `common` and into `preview`
for good measure.
* Show all file-local componanets (check is-exported)
* Parse all known files before generating the file list
Keep the document_cache with all the extra documents loaded around,
The property editor built into the live-preview now comes with the
concept of a "simple/complex mode". There is a "K" (for complex, obviously;-)
or a "S" (for simple, just as obvious) beween the property name and property
value. you can click on the letter to switch from simple to complex mode,
but you can only switch back to simple mode if there are no complex expressions
in the line edit.
This implements a "simple" mode for bools.
# Todo
* [ ] Find icons for simple/complex mode:-)
* [ ] Figure out how to decide whether other types are "simple"
* [ ] Define more UIs for simple types
live-preview: Move simple property code into rust
... and handle simple strings in addition to bool.
