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.
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
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.
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
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.
... by rendering the elements as transparent. They are still
there and work, so you can still resize, but you still get a
better view of your UI.
We still draw a border around the UI, just to show where
it ends and the background begins, but that is purely
decorative :-)
I am not totally happy wioth this: It still sets mouse cursors
in the area that should actually be controlled by the UI and
overlays its own touchareas around the border of the UI, stealing
a few pixels from the interactive area of 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!
For beauty-reasons we no longer report `Empty` though and replace
that with `""`. This prevents the property editor from showing a UI:
The `type-name` field being empty was abused to indicate that no
data is available -- we do not have options in Slint :-/
Replace that test with the length of the model holding the properties.
We assume we got no data when that model is empty... which is probably
a safer bet for "no property data availabel" than the `type-name`
field.
