The problem is that the file stays in the `currently_loading` hashmap
and therefore we thinkg we need to await for the result, while it is not
actually loading
Regression since f1f5a86d0dFixes#3468
The parent is already deleted when we delete the component that is kept
alive by the `grabber` ItemRc in `handle_mouse_grab`
When the ItemRc goes out of scope, we delete the component, but the
parent was already gone.
This doesn't solve a broader issue that we use the parent in many place
and it is not kept alive (for example when using properties of the
parent)
Since they no longer have a builtin width/height property, the test
that checked the type was wrong. But since we can't override the width
or height property with another type, this should not be relevant
This doesn't work yet as we need to do more "patching" of anything that
uses the x and y properties
This reverts commit 2d6fec78f9ff01c8b4904685fae0ce587a3c8e9a and
036ddfe23aa5f5b63778b8056d58c30c08f942fe.
The WindowItem did not have a x or y before, so these property
were unused for it's geometry(), but now it is used in the new
item_geometry on the ComponentVTable.
So make sure we don't initialize them
This PR updates the logos and branding guideline of Slint to match the new website design. The new logos are a 1:1 replacement of the old logos except for the circular logo. In the new logo design, there isn't a separate circular logo, as the square logo with circular crop can be used. Further, the logo folder also contains logos in CMYK for use in printed materials. The PMS is just the color value in the naming and can be used where Pantome colors are required. The README has been updated to explain which logos to use when as well as the Slint "blue" color.
* Optimize StandardTableView in Fluent and Material styles
By using a ListView instead of a ScrollView + VerticalLayout, we trigger
the optimization where only visible children are being instantiated.
For the Fluent style, this was making the rows more compact, so I've
added additional padding to the TableViewCell to compensate. I don't
know where the padding used to come from.
I didn't touch Cupertino style since it's currently work-in-progress.
This optimization can be done there as well.
For the Native style, this optimization isn't as straight-forward
because it uses a NativeScrollView + Flickable directly rather than a
the ScrollView.
* Optimize StandardTableView for Native style
Using the ListView makes it possible to only instantiate the visible
items, which makes the StandardTableView a lot faster for larger models
(already very noticeably in the gallery example).
When using a ListView, StandardTableView lost access to the
NativeScrollView.native-padding-top/left properties, which are now
exposed through the ScrollView item.
It could also no longer position the Flickable below the header (or in
doing so, would take the scrollbar along with it), so a property was
added to ScrollView for that purpose as well.
* Introduced InternalScrollView
This avoids exposing additional properties on the ScrollView for just
the native style.
* Fix missing default values for Native style ScrollView
Added minimum size, preferred size and stretch factors (they were not
present before introducing InternalScrollView either, but are added now
for consistency with the other styles).
So it doesn't appear in the LLR and the C++ codegen can be simplified.
In particular, this removes the need to throw/catch exception to handle return
across generated lambdas
It specified a height: 100% which set the layout info to have a
`min_percent: 100.0` which bubbles on other layout.
Arguably that's a bug in layouts but this 100% shouldn't be there.
CC: #3346
In the case of bug #3318, the implicit alias to the window's height or
width was removed but the propery was not marked as externaly modified,
causing later pass to optimize and inline things that shouldn't
Fixes#3318
Unfortunately, this is currently not mapped to the right keyboard layout
Also keep the mouse clamped in the visible area.
And make it start in the middle of the screen.