[Development] QTCS2019 Notes from QtQml session

[Simon Hausmann]

On 25.11.19 16:55, Robin Burchell wrote:
> On Mon, Nov 25, 2019, at 3:53 PM, Ulf Hermann wrote:
>> Yes, but the problems with this construct are the same as with generic
>> context properties: Your QML component requires some context that it
>> doesn't declare. Therefore your code is not reusable and brittle wrt
>> addition of properties in other places.
> Which is why I also provided a possible solution - by providing declaration of that context.
>
> I'm not sure whether you just stopped reading once I started talking about the problem, but I'd be interested to hear about whether or not something like that approach was considered.


I think the approach that you described is semantically almost identical 
with required properties. Instantiation of such a component requires 
providing context and at the same time it's possible to keep 
dependencies within the boundaries of a component.

>
>> Mind that all those dynamic lookups will still live on in QML 2, and we
>> will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.
> It's good to hear that QML 2 won't disappear overnight, but let's not pretend that this would be a sustainable, good situation to be in. One day, QML 2 will disappear. At least, given the lower version number, you would hope it will disappear. But every piece of pain that makes porting harder will help to ensure that it stays around longer.
>
> And even if there wasn't going to be pain in porting - there is going to be a lot of residual friction in transitioning. All of the documentation, all of the examples, all of the tribal knowledge will suddenly become irrelevant.
>
> And for what? Why?
>
>
> Yes, there are problems with some features. That doesn't necessarily mean they are unsolvable problems (perhaps they are; without having a proper discussion about it - how do we know?)
>
> By the sounds of it, QML2 to QML3 will not be an easy transition. I was already a little worried when I saw changes removing versioning, and a WIP change deprecating context properties back in April or so, but reading your mail makes me very concerned for the future.
>
> For reference, QML1 to QML2 was a _relatively_ easy port for example, despite a different JavaScript engine, a new item set, and a completely rewritten graphical presentation. My personal opinion is that this was very good, because it gave you a pretty big no-brainer: spend a small moderate amount of effort to port and validate/test, and in return, you gain much better performance.
>
> The situation for QML3 seems to be much less clear cut

Often we do transitions in Qt API to improve performance or perhaps 
interoperability. Take the discussion about the return type of size() 
for example, or whether QList should alias QVector or not.

I sincerely hope that this transition will be different - at least today 
it looks already different to me and we're well into it in 5.15. The 
objective is to improve the maintainability of the user's code. We have 
added significant functionality to the linter and there is more to come. 
We're in the process of always applying it at build time to our own 
code. The work there is the foundation for the future tooling around the 
entire language, from a new compilation to C++ as well as better IDE 
integration. The current IDE integration is at its very limits (with 
cool hacks like scanning the C++ code for qmlRegisterType calls). Most 
of it boils down to the ability to make sense out of what's in the QML 
file without running the entire program.

Dynamic scoping and context properties make it hard (sometimes 
impossible) to reason without running - I anticipate agreement on this :-)

The application of singletons as well as required properties in our own 
examples has significantly improved the readability of code - that gives 
me the confidence that we're on the right track. Those may not be the 
two solutions that solve everything - however I find the evidence 
compelling. And by applying this step by step today, we're not making 
our examples and documentation irrelevant, we're transitioning and 
learning from it.


Simon