This swaps the text editor to the right and thus makes room for the Slint built-in menu bar. In Slintpad, the menu bar shows two additional entries in the File menu:
- The "Open Demo" sub-menu originates from the earlier web menubar and forwards to the editor.
- The share menu item is also quite useful from the web menu, but is now implemented by means of directly copying to the clipboard.
Rely on the fact that `component_instance.component_positions` read
properties and do the property tracking for us. By accessing it from a
callback we get free dirty notification.
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>
Rename svg color to css.
Ensure 'Apply' is at the bottom in all modes.
Give empty recent colors a frame so there isn't a huge empty space when there are no recents.
Tweak the layout based on these changes.
... for the duration of the session. How can we save those
colors?
Recent colors change a lot, we probably do not want that stored
inside the git repository hosting the slint files... and this is
probably "personal data" and nor "project data" in the first place.
Find color names/values defined in palettes in property bindings.
Make sure to not report those as code.
Do a lot more complex evaluation of color values "behind" the palette name
to get a useful value out for the palete name. This will e.g. follow the
true branch of conditions, handle Structs, struct field access and references to
globals when looking for the color value.
live-preview: Keep gradient stops sorted
... when reading them from code and when inserting
new stops.
* live-preview: Add a API to move gradient stops
Gradient stops need to be sorted now, so we need to
have a new API for moving gradient stops -- so the
model can stay sorted as we drag stops around.
So that we can pass the focus into the container when it first
shows.
I thought this would be super complex to do property! What a
nice surprise:-)
Fixes: #4055
Only push basic information over the boundary in a model.
The values themselves now need to be queried via `Api`.
Pros:
* Slint tracks the properties automatically, no more
Property change tracker!
Cons:
* Live preview is less useful now as we can not yet provide
function call results via ourr data API.
We can now set all the properties exposed to the
business logic of a UI we are previewing.
Simple properties only so far, everything else falls
back to JSON data.
Next step is to add more sophisticated UI to actually
edit more complex data like arrays more graphically.
* live-preview: More filter options in Selection Popup
* Hide layouts,
* Hide interactive elements
* Hide others
@szecket did a lot of UI polish that I just merged here
so that I do not need to show what I made!
* live-preview: Remove TouchArea suffix
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.
* 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>
