Fix compiler panic when using % size in a flickable

[ogoffart]

The viewport of a flickable is of ElementType::Native, and lookup_property don't query the builtin reserved properties in that case.

This commit fix the assert by allowing Type::Invalid as well.

Fixes #4163

[ogoffart]

The question is if we should not change the meading of 100% to be the "semantic" parent: So to be the size of the flickable and not the viewport (see test)

[tronical]

I suppose this part is not needed for the automated test?

[ogoffart]

this is the original testcase. Not needed but good to have in addition as it is a bit more complex.

[tronical]

Note that our terminology is wrong: the viewport is the "portion" that's visible. So the % applies to the content width, not the viewport width - while parent refers to the content.

The inconsistency is not good.

Since the % asserts right now, I guess aligning it with parent would be the "compatible" fix.

I'm inclined to say that parent referring to the content size would make more sense to me, as the Flickable can always be referred to by name. But I think that would be a breaking change.

[ogoffart]

Note that our terminology is wrong: the viewport is the "portion" that's visible. So the % applies to the content width, not the viewport width - while parent refers to the content.

The inconsistency is not good.

parent doesn't refer to the content, it refer to the flickable itself.

"content" and "viewport" are two name for the same things. We seem to use viewport consistently.

But it's true that you already filled an issue to replace that. #1443
But that's out of scope of this PR

[ogoffart]

Since the % asserts right now, I guess aligning it with parent would be the "compatible" fix.

It asserts in debug mode in Slint 1.3.x But it used to work in 1.2

But yes, i agree we can still do this change if we want.

I'm inclined to say that parent referring to the content size would make more sense to me, as the Flickable can always be referred to by name. But I think that would be a breaking change.

I'm not sure i understand this.

What is the "content size"? parent doesn't refer to a size, it refer to an element.
And parent refer to the parent element in the AST as it is resolved. So you can say parent.interactive or parent.foobar if there is a foobar property declared in the flickable.

But currently % refer to the viewport size which is the same as the content size isn't it?

So you think that's how it should be and that the current behavior is correct?

[ogoffart]

this is the original testcase. Not needed but good to have in addition as it is a bit more complex.

[ogoffart]

Note that our terminology is wrong: the viewport is the "portion" that's visible. So the % applies to the content width, not the viewport width - while parent refers to the content.

The inconsistency is not good.

parent doesn't refer to the content, it refer to the flickable itself.

"content" and "viewport" are two name for the same things. We seem to use viewport consistently.

But it's true that you already filled an issue to replace that. #1443
But that's out of scope of this PR

[tronical]

Oops, I made indeed a mistake in terminology and expression.

I thought about it again.

I think it's good that parent refers to the Flickable (instead of that invisible Rect "inside"). That's consistent.

I can't imagine what a mess it would be to document and explain that % in this context is not equivalent to an expression that uses parent, so I'm very much in favor of aligning % with parent and keeping the current meaning of parent to refer to the Flickable itself.

In terms of use cases for parent here I'm a bit at a loss. I'd imagine a lot more folks wanting to express sizes relative to the content width/height (what's currently called viewport-{width/height}. That's easily done with a binding expression and that's very readable.