It does not work too well and it breaks switching between LineEdits
in the property editor. Downside: We have no more way to delete the
selected element anymore. We could have it in a tool button, but
IMHO we should have Undo before we make it that obvious.
* floatwidget and ResettingLineEdit updated
* ColorWidget adjusted
* most attributes visible again
* spacing more consistent and added italic to not-edited double encoding
* all controls rendering.
* consistent sizes for all column distributions.
* removed debug code and optimized logic a bit
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.
Back in Slint 1.6, slintpad had a "welcome" page that explained what it is.
But the welcome page was removed in commit 588ee3e474
Now it's hard for someone who click on a link to slintpad.com to know
what it is and get a link to Slint.
Add an "about" entry in the menu that shows the previous welcome page as
a dialog
ChangeLog: Slintpad: add "about" entry in the menu.
Stop abusing the init callback, abuse the changed callback instead ;-)
Also merge the initial size calculation into one place. This fixes the
preview showing the wrong sizes. It does introduce a bit of flicker though
as the UI is rendered in the wrong state once and then immediently corrects
itself.
That is annoying, but strictly better than staying in the wrong state till
the user does something.
Closes: #5954
Don't change any whitespace before or after a comment.
We were already preserving whitespaces after comment, do the same for
whitespaces before comments
ChangeLog: formatter: don't change whitespaces or newlines before comments
Use the entire screen-space (minus borders) when the preferred size
of a UI is 0 and we are asking to reset to the preferred size.
I was reluctant to implement this before as I think it is surprising
to start with a huge size when the size info is most likely wrong...
People typically render outside the component's area in that case.
Now that we clip away anything that is not inside the UI area, I think
this is discoverable enough now: When resizing you will see the UI
getting clipped after all.
The big size also avoids confusion when nothing shows up :-)
* live-preview: Polish the header-view
* live-preview: Clean up the previous patch a bit
---------
Co-authored-by: Tobias Hunger <tobias.hunger@slint.dev>
Clip anything the previewed UI wants to draw outside
of the area the previewed component claims to be using.
There are several reasons to do this:
* A window will clip the contained component
* Selection outside of the area taken up by the
root component can not be selected or interacted
with
* It is more obvious that you are doing something
wrong when your UI is clipped. Before we happily
showed the right thing in the preview and then
failed hard when using that component.
This means that, when the parent is not a layout, the widgets are
always dropped in the middle of the parent, and then one can place
place it to the right position.
In particular, for widget that expaneds to the size of their parent by
default, this does the right thing
Fixes#6098
We did not have the compile-test infrastructure when
implementing the addition of new components into a UI. Use that
infrastructure, it catches some places where we can not actually
drop into that the previous heuristic missed.
Otherwise we end up with values such as
```slint
SpinBox {
minimum: 0;
value: 42;
maximum: 100;
x: 94.44821px;
y: 108.07013px;
}
```
Which doesn't make much sense
For example, running the viewer with a DISPLAY wrongly set:
Before the patch:
```
thread 'main' panicked at tools/viewer/main.rs:123:32:
called `Result::unwrap()` on an `Err` value: Other("Could not initialize backend.\nError from Winit backend: Error initializing winit event loop: the requested operation is not supported by Winit\nError from LinuxKMS backend: Timeout while waiting to activate session\nNo backends configured.")
stack backtrace:
[...]
```
If just using `?` instead of `.unwrap()`:
```
Error: Other("Could not initialize backend.\nError from Winit backend: Error initializing winit event loop: the requested operation is not supported by Winit\nError from LinuxKMS backend: Timeout while waiting to activate session\nNo backends configured.")
```
If using an wrapper that uses Display for Debug
```
Error: Could not initialize backend.
Error from Winit backend: Error initializing winit event loop: the requested operation is not supported by Winit
Error from LinuxKMS backend: Timeout while waiting to activate session
No backends configured.
```
