[Development] QTCS2019 Notes from QtQml session
Simon.Hausmann at qt.io
Tue Nov 26 11:41:31 CET 2019
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.
> 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.
More information about the Development