Re: [Development] QTCS2019 Notes from QtQml session
Am 25.11.2019 um 15:39 schrieb André Somers: On 25-11-19 12:31, Ulf Hermann wrote: I think one of the biggest problems is that ID resolution crosses file boundaries. This essentially means that the ids chosen can very easily become part of the "API" of a component unless you are very vigilant to not allow that to happen. Well, yes, and there is an easy way to fix this: Deprecate id lookup across file scope. id lookup is actually the same as context property lookup right now. That's what you're seeing there. We cannot get rid of IDs, obviously, but we can restrict their use to the file context and not search the whole context hierarchy. Yeah, that's going to make using QML in actual applications a whole lot harder. For instance, sometimes access to some root node is needed even from deep leaf files. Removing that capability is quite a drastic measure. Create a singleton for that root object properties that have to be globally accessible. Additionally we have these attached properties which can serve a similar purpose. Ciao Mathias ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
> On 25 Nov 2019, at 22:18, Filippo Cucchetto > wrote: > > Having followed the evolution and first announcement of Qml/Quick QML3 seems > like an admission of guilt. > I remember when a lot of people complained about the use of Javascript as a > scripting language and further > more on the lack of a public C++ API. Now it seems like some of the QML > problems are going to be fixed > but still i wonder if instead of putting man power in cutting QML2 we could > bring first citizen C++ QtQuick API. > Playing the devil's advocate why can't we leave QML2 as is and instead use > the new pseudo declarative > C++ syntax and code everything in C++? I mean...we want speed? you want > speed? use plain C++. There’s nothing wrong with a little syntactic sugar, as long as we stay committed to the translation that we choose. A code generator that starts with QML source is not worse than moc or uic or qrc. (I still think we could have done better performance-wise by writing a real compiler rather than writing C++ source code that then needs to be parsed again, but at least you will presumably have a chance to read the C++ code that it generates, which should help with understanding what it does.) Another thing that came up at QtCS though (during the break, not during the session) is that as soon as we make it possible for customers to ship binaries that run QML that has been compiled in C++ form, rather than interpreted QML, if those same customers also expect the usual binary compatibility guarantee (to be able to upgrade Qt and still keep running the same compiled binary), then it’s a precondition to apply the same binary-compatibility rules to everything that Qt Quick exposes to QML. Those headers will have to follow the same rules that every other public API does. That worries me a bit, because it will remove a degree of freedom that we have enjoyed in Qt 5, which made it easier to fix API mistakes, extend existing APIs to support different data types, etc. If we will lose flexibility to change any QML-exposed APIs in any binary-incompatible way after Qt 6, then we might as well make all the headers public too, right? The only reason they weren’t (that I’m aware of), was to retain flexibility to change C++ API, as long as QML API continued to work the same. This will satisfy people like you who keep asking for C++ API over and over, but also will make it much harder to fix any API mistakes that remain. So it seems that there’s a really big chunk of work I didn’t know about, to get ready for Qt 6: use the PIMPL pattern everywhere (we mostly did that already though), rename the headers, make sure the data storage is always in the private class, do API review of _everything_ to make sure we aren’t exposing any unmaintainable public C++ API, make sure our use of data types is consistent, etc. And that’s for every module that exposes anything to QML, not just in qtdeclarative. Other things that we could be doing will probably need to be postponed because of that. For example we still aren’t sure whether QVariant, QVariantList and such are good data types to use in QML-exposed APIs, and therefore haven’t been consistent about it. We might end up wanting to change most of those. Before, the QML engine could pave over some of the details for us (there are multiple ways to expose containers and composite objects, so it's been fine until now to use them all), but if we will have public API, we should be consistent. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 26 Nov 2019, at 12:35, Olivier Goffart mailto:oliv...@woboq.com>> wrote: On 25.11.19 16:36, André Somers wrote: On 25-11-19 15:53, Ulf Hermann wrote: Yeah, that's going to make using QML in actual applications a whole lot harder. For instance, sometimes access to some root node is needed even from deep leaf files. Removing that capability is quite a drastic measure. 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. 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 will still work in QML 2" is not a great one if you want people to port over to QML 3. And you will need to support something like this anyway. So far, the feeling I'm getting is that you're quite rigorously axing things from QML 2 in QML 3 in order to clean up because it is "broken" in QML 2. But without careful consideration what should replace it, that will just lead to the same issues again or a less usable QML for real world applications. I'm a bit concerned. Maybe the marketing isn't quite right. Perhaps it shouldn't be named "QML 3" but "QML strict" QML3 tell peolpe "This is the new version, you should port your code, the old version is going to be deprecated at some point" While maybe true, I understand people's frustration. And since you will need to maintain both QML2 and QML3 at the same time, it might be better to rename it to something like "QML Strict" which convey the meaning: "QML Strict is as subset of QML which is more maintainable and performs better” I agree, was just going to write a comment about that. If we will continue to support QML 2 for cases when the runtime engine is useful, for the foreseeable future, then QML 3 isn’t really the successor, is it? If QML 3 was the successor, the ability to run QML without compiling it first would be sorely missed. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 27/11/2019 11:39, Milian Wolff wrote:
Personally, I hope the answer is that this will remain supported. The only
disadvantage is the runtime type introspection, which should/could be solved
via Ulf's idea of something like an inline interface/trait component. Such
that eventually we can do something like:
```
interface ModelData { // syntax is open, just to give an idea
required property string text
required property int answer
}
delegate: Text {
required property ModelData model // model is a misnomer, but I digress
text: model.text + model.answer
}
```
Yes, I totally get this part. But I'm asking specifically about the
future of "required property var model" bit, at least for two good reasons:
1) the sake of porting existing code, and/or
2) in case the above doesn't materialize for 6.0
I think I completely misunderstood something during the session and thus
my question here :)
Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On Tue, Nov 26, 2019, at 8:56 AM, Ulf Hermann wrote:
> We're also changing the way views and delegate work. If you want to use
> the "index" in a Repeater's delegate you'll have to declare that in QML
> 3, using a required property:
>
> Repeater {
> model: 10
>
> Text {
> required property int index
> text: "item " + index
> }
> }
Can you explain a bit more about what the concrete problem is with model data
on delegates? Speaking specifically about inline delegates[1] like the one you
give here.
In many cases, like the one you provide, is the additional required statement
really required? ;-) - when it's clear that the component is a delegate, it
seems rather redundant and annoying to have to specify additional 'required'
statements to be able to use the data that is always provided by the model's
context. I don't see why it makes sense to require an inline delegate to say
"hello, I am a delegate, please give me a delegate's properties" when you
already specified that it is a delegate when you wrote the component a line or
two above.
Perhaps I'm missing something, or perhaps this will only apply for external
delegates in a different file - but my opinion is that for inline delegates, I
think it would be an acceptable limitation to continue to 'hijack'
model/modelData/index on a permanent basis without any additional syntax.
Given that such inline delegates are so very, very frequently used, I think
that the bar for changing how that works in a user-visible way should be quite
high.
[1]: I suppose this would only really apply for inline components, too, where
it's clear that the component is used only in conjunction with the view in
question, but I think that's fine. Inline delegates are way more common than
external delegates (IME) and are also written as throwaways quite frequently
during quick prototyping, which should be as easy as possible ideally.
If your delegate gets complicated enough to split out to a separate file for
reuse or autotesting purposes, then sure, requiring a specification of what
that component uses of course makes a lot of sense, and I would be in full
favour of that, having been bitten by a few bugs in those cases.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On Mittwoch, 27. November 2019 10:35:23 CET Giuseppe D'Angelo via Development
wrote:
> Il 27/11/19 09:52, Ulf Hermann ha scritto:
> > That depends on how we do the model/delegate matching mentioned above.
> > As stated above, I don't have a solution, yet. If you have an idea, let
> > us know. I can imagine generating some C++ from such code that does the
> > model/delegate matching at run-time via the metaobject system. That way
> > we would support var models.
>
> Well, neither do I :) It would also be nice to find a similar solution
> for widgets and delegates. And to be honest such solution could also
> come later than 6.0?
>
> The other side of the question, for long term running projects, is
> simply: will the injected "model" required property on delegate
> properties be fully supported throughout QML2/3 or is it immediately
> deprecated and just a porting measure?
Personally, I hope the answer is that this will remain supported. The only
disadvantage is the runtime type introspection, which should/could be solved
via Ulf's idea of something like an inline interface/trait component. Such
that eventually we can do something like:
```
interface ModelData { // syntax is open, just to give an idea
required property string text
required property int answer
}
delegate: Text {
required property ModelData model // model is a misnomer, but I digress
text: model.text + model.answer
}
```
Cheers
--
Milian Wolff | milian.wo...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On Dienstag, 26. November 2019 20:32:20 CET Arno Rehn wrote:
> On 26/11/2019 08:56, Ulf Hermann wrote:
> >> We have some code that evaluates JS in custom QQmlContexts with certain
> >> "magic" context properties set (sort of like the "index" or "modelData"
> >> context properties in delegates like Repeater.delegate).
> >> Will something similar still be possible?
> >
> > You should rephrase that as required properties on actual objects. Then
> > the magic won't work anymore and you'll have to look up the properties
> > by ID of the object, but that is a good thing. It will improve
> > re-usability of your components.
>
> Right, that would work in this case. Thanks!
>
> Anyway, how would I idiomatically register a bunch of dynamically
> created C++ objects with QML then? As an example, we're automatically
> detecting hardware stuff and creating interface objects based on that.
> These interface objects are then passed to QML which we use to implement
> state machines.
>
> Pseudo-code example:
>
> QObjectList objects = detectAndCreateObjects();
> QVariantMap qmlObjects;
> for (auto object : objects) {
> qmlObjects[object->objectName()] = object;
> }
> engine->rootContext()->setContextProperty("Objects", qmlObjects);
>
> Now I see two (maybe more) "workarounds" for that:
> 1. Register every object as a singleton. That's bad design, because
> these objects don't really match the singleton pattern.
> 2. Register a single accessor singleton instance which holds the
> qmlObjects. That's a lot more to type, though:
>
> import QtQml.StateMachine 1.0 as DSM
> import Utils 0.1 // provides "ObjectProvider"
>
> DSM.State {
> onEntered: ObjectProvider.objects.foobar.frizzle()
> // In QML 2:
> // onEntered: Objects.foobar.frizzle()
> // or even just:
> // onEntered: foobar.frizzle()
> // if we leave out the QVariantMap above
> }
>
> I realize that this makes things more "well defined". But I think it'll
> make usage of QML as a domain-specific language (like for implementing
> state machine logic) a little more cumbersome.
The third option is to add a `required property` on your root object and
instantiate your context with the `qmlObjects` directly. Then you pass that
through to your state machine.
Both of these options are "more typing" but at the same time the code becomes
more explicit and thus easier to refactor and interpret by tools.
Bye
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Il 27/11/19 09:52, Ulf Hermann ha scritto: That depends on how we do the model/delegate matching mentioned above. As stated above, I don't have a solution, yet. If you have an idea, let us know. I can imagine generating some C++ from such code that does the model/delegate matching at run-time via the metaobject system. That way we would support var models. Well, neither do I :) It would also be nice to find a similar solution for widgets and delegates. And to be honest such solution could also come later than 6.0? The other side of the question, for long term running projects, is simply: will the injected "model" required property on delegate properties be fully supported throughout QML2/3 or is it immediately deprecated and just a porting measure? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
>> We brainstormed a bit about how a model could declare its items' data >> type in QML, so that we could statically check model against delegate >> types. We will need this when compiling QML 3 to C++. We didn't come up >> with anything really great, though. This needs more work. > > Just something specifically related to models and delegates: having a > > required property var model > > on the delegate, then using model.foo (just like today), is supposed to > be a fully supported measure throughout QML2/3 or just a > deprecated-on-birth porting solution towards explicit required > properties on the delegate? That depends on how we do the model/delegate matching mentioned above. As stated above, I don't have a solution, yet. If you have an idea, let us know. I can imagine generating some C++ from such code that does the model/delegate matching at run-time via the metaobject system. That way we would support var models. - Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
> Anyway, how would I idiomatically register a bunch of dynamically
> created C++ objects with QML then? As an example, we're automatically
> detecting hardware stuff and creating interface objects based on that.
> These interface objects are then passed to QML which we use to implement
> state machines.
You can have a QJSValue as singleton. There is a
qmlRegisterSingletonType() that takes a QJSValue factory function. That
QJSValue can be an object (QJSEngine::newObject()) and the object can
have arbitrary properties, keyed by strings. Note that you should really
only do this if you need all the flexibility of creating a completely
unpredictable "bag of objects". You're deferring all the type checking
and property resolution to run-time this way.
In QML that would be:
import QtQml.StateMachine 1.0 as DSM
import Utils 0.1 // provides QJSValue singleton "Objects"
DSM.State {
// just as if "Objects" were a context propery
onEntered: Objects.foobar.frizzle()
}
Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Il 21/11/19 09:17, Ulf Hermann ha scritto: Typed Model Data We brainstormed a bit about how a model could declare its items' data type in QML, so that we could statically check model against delegate types. We will need this when compiling QML 3 to C++. We didn't come up with anything really great, though. This needs more work. Just something specifically related to models and delegates: having a required property var model on the delegate, then using model.foo (just like today), is supposed to be a fully supported measure throughout QML2/3 or just a deprecated-on-birth porting solution towards explicit required properties on the delegate? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 26/11/2019 08:56, Ulf Hermann wrote:
>> We have some code that evaluates JS in custom QQmlContexts with certain
>> "magic" context properties set (sort of like the "index" or "modelData"
>> context properties in delegates like Repeater.delegate).
>> Will something similar still be possible?
>
> You should rephrase that as required properties on actual objects. Then
> the magic won't work anymore and you'll have to look up the properties
> by ID of the object, but that is a good thing. It will improve
> re-usability of your components.
Right, that would work in this case. Thanks!
Anyway, how would I idiomatically register a bunch of dynamically
created C++ objects with QML then? As an example, we're automatically
detecting hardware stuff and creating interface objects based on that.
These interface objects are then passed to QML which we use to implement
state machines.
Pseudo-code example:
QObjectList objects = detectAndCreateObjects();
QVariantMap qmlObjects;
for (auto object : objects) {
qmlObjects[object->objectName()] = object;
}
engine->rootContext()->setContextProperty("Objects", qmlObjects);
Now I see two (maybe more) "workarounds" for that:
1. Register every object as a singleton. That's bad design, because
these objects don't really match the singleton pattern.
2. Register a single accessor singleton instance which holds the
qmlObjects. That's a lot more to type, though:
import QtQml.StateMachine 1.0 as DSM
import Utils 0.1 // provides "ObjectProvider"
DSM.State {
onEntered: ObjectProvider.objects.foobar.frizzle()
// In QML 2:
// onEntered: Objects.foobar.frizzle()
// or even just:
// onEntered: foobar.frizzle()
// if we leave out the QVariantMap above
}
I realize that this makes things more "well defined". But I think it'll
make usage of QML as a domain-specific language (like for implementing
state machine logic) a little more cumbersome.
Regards,
Arno
--
Arno Rehn
Tel +49 89 189 166 0
Fax +49 89 189 166 111
a.r...@menlosystems.com
www.menlosystems.com
Menlo Systems GmbH
Am Klopferspitz 19a, 82152 Martinsried, Germany
Amtsgericht München HRB 138145
Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
USt.-IdNr. DE217772017, St.-Nr. 14316170324
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 11/26/19 12:35 PM, Olivier Goffart wrote: "QML Strict is as subset of QML which is more maintainable and performs better" Isn't it that way: QML is for convenience but expensive. C++ is often less convenient but with better performance and lower memory footprint. QML Strict is a compromise - something in between. Then people can make a conscious decision, what is the right choice for their situation. IMHO being honest about what is what makes more sense, than how it was f.e. done with QC2. That was sold as something specific for embedded but actually it was about replacing QML by C++ code to get around performance issues. My 2 cents, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
> Lookup by ID? You mean set the object name like you did in your example
> in your talk at QtWS? I protested then, and I will protest now again.
> Don't. Really: don't. If you are talking about re-usability and
> maintainability of your code elsewhere, then advocating this practice is
> really wrong. You need to layer your QML on top of an API provided by
> C++, not poke into your QML from C++.
Maybe that example in the slides was not so great. However, consider:
// main.qml
Item {
required property string title
}
// somewhere.cpp
QQmlComponent component(, ":/main.qml");
QObject *obj = component.createWithInitialProperties(
QVariantMap { {"title", "Hello World"} });
This declares the property in QML and requires you to set it when
instantiating the component. The object won't be created if you fail to
set the property. We may improve on this in the future. QQmlComponent
already has a separate setInitialProperties() function, and we might add
another one to check if all required properties are set.
I had to introduce the replacements for context properties in some
order, and, apparently, introducing required properties first would have
been better. Sorry for the confusion.
Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 25.11.19 16:36, André Somers wrote: On 25-11-19 15:53, Ulf Hermann wrote: Yeah, that's going to make using QML in actual applications a whole lot harder. For instance, sometimes access to some root node is needed even from deep leaf files. Removing that capability is quite a drastic measure. 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. 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 will still work in QML 2" is not a great one if you want people to port over to QML 3. And you will need to support something like this anyway. So far, the feeling I'm getting is that you're quite rigorously axing things from QML 2 in QML 3 in order to clean up because it is "broken" in QML 2. But without careful consideration what should replace it, that will just lead to the same issues again or a less usable QML for real world applications. I'm a bit concerned. Maybe the marketing isn't quite right. Perhaps it shouldn't be named "QML 3" but "QML strict" QML3 tell peolpe "This is the new version, you should port your code, the old version is going to be deprecated at some point" While maybe true, I understand people's frustration. And since you will need to maintain both QML2 and QML3 at the same time, it might be better to rename it to something like "QML Strict" which convey the meaning: "QML Strict is as subset of QML which is more maintainable and performs better" -- Olivier ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 26.11.19 11:48, André Somers wrote:
>
> On 26/11/2019 08:56, Ulf Hermann wrote:
>>> We have some code that evaluates JS in custom QQmlContexts with certain
>>> "magic" context properties set (sort of like the "index" or "modelData"
>>> context properties in delegates like Repeater.delegate).
>>> Will something similar still be possible?
>> You should rephrase that as required properties on actual objects. Then
>> the magic won't work anymore and you'll have to look up the properties
>> by ID of the object, but that is a good thing. It will improve
>> re-usability of your components.
> Lookup by ID? You mean set the object name like you did in your
> example in your talk at QtWS? I protested then, and I will protest now
> again. Don't. Really: don't. If you are talking about re-usability and
> maintainability of your code elsewhere, then advocating this practice
> is really wrong. You need to layer your QML on top of an API provided
> by C++, not poke into your QML from C++.
We're drastically improving the ability to layer QML on top of an API
provided by C++. It means that we need to know what that C++ API looks
like when looking at the .qml file without running it, for example when
linting. This is why we're moving to the model of declarative C++ type
registration and extraction of the "moc visible" API (slots, properties,
etc.) at build time. That way we can give you feedback that perhaps
you've accidentally used the wrong name of a C++ backed property at
build (or editing time), instead of through "returning undefined" at
run-time when accessing it.
>>
>> We're also changing the way views and delegate work. If you want to use
>> the "index" in a Repeater's delegate you'll have to declare that in QML
>> 3, using a required property:
>>
>> Repeater {
>> model: 10
>>
>> Text {
>> required property int index
>> text: "item " + index
>> }
>> }
>
> I really, really dislike this change. It looks even more like magic
> than what we have today. By all means deprecate/get rid off looking up
> without using `model.` in front of index, but what you write there
> really looks like magic. It is totally unclear who is setting a
> property (required or not) if you just declare it. This introduces
> more magic instead of less, and would IMO lead to more knowledge
> required in on the C++ side about the QML side of the application,
> where I just argued above that that leads to bad practice.
>
You say that it's unclear who is setting a (required) property. The
analogy that we've used is that required properties are like declaring
function parameters - you expect the caller to provide them, but you
don't really care where the caller provided them from. Think of the
above text delegate like a factory function (except that the parameters
are live bindings):
(pseudo code)
function createDelegate(index: int) {
return new Text("item " + index);
}
That doesn't feel like magic to me.
Simon
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 26/11/2019 08:56, Ulf Hermann wrote:
We have some code that evaluates JS in custom QQmlContexts with certain
"magic" context properties set (sort of like the "index" or "modelData"
context properties in delegates like Repeater.delegate).
Will something similar still be possible?
You should rephrase that as required properties on actual objects. Then
the magic won't work anymore and you'll have to look up the properties
by ID of the object, but that is a good thing. It will improve
re-usability of your components.
Lookup by ID? You mean set the object name like you did in your example
in your talk at QtWS? I protested then, and I will protest now again.
Don't. Really: don't. If you are talking about re-usability and
maintainability of your code elsewhere, then advocating this practice is
really wrong. You need to layer your QML on top of an API provided by
C++, not poke into your QML from C++.
We're also changing the way views and delegate work. If you want to use
the "index" in a Repeater's delegate you'll have to declare that in QML
3, using a required property:
Repeater {
model: 10
Text {
required property int index
text: "item " + index
}
}
I really, really dislike this change. It looks even more like magic than
what we have today. By all means deprecate/get rid off looking up
without using `model.` in front of index, but what you write there
really looks like magic. It is totally unclear who is setting a property
(required or not) if you just declare it. This introduces more magic
instead of less, and would IMO lead to more knowledge required in on the
C++ side about the QML side of the application, where I just argued
above that that leads to bad practice.
André
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 25.11.19 12:15, Robin Burchell wrote:
>> We could detect this in qmllint by just continuing the search for IDs
>> even if we've found a property.
> We could, but if I may gently suggest, I think I can count most of the people
> who use qmllint on a regular, useful basis on one hand ;-).
You're soon going to run out of fingers ;-)
> (One possible improvement to this could be to not _just_ have it as a
> separate tool: maybe debug builds should _also_ run qmllint - or at least a
> subset of its checks - on the code that the engine is loading? Alternatively,
> perhaps as an engine flag to at least allow it to be turned on once, and
> happen for everyone on a team in a unified zero-effort way)
Yes, we're working on integrating the application of the linter into the
build system, so that it is always run. The objective is to look at the
qml code as early as possible in the development cycle. Right now it's a
run-time, maaybe a little at compile time with CONFIG +=
qtquickcompiler. The linter is taking a much closer look at the qml file
(beyond the code in binding expressions) and that's feedback to be given
after pressing the shortcut for "Build". We'd like to take the same code
and place it into a language server, so that the feedback can be given
right after typing - before choosing the apply the build step.
>> Mind that adding a method to a base class in C++ will shadow unrelated
>> other classes and functions even if it's not virtual or overridden. Why
>> did we actually decide that we can live with this effect in C++ but not
>> in QML? - Maybe because in C++ it's more likely to result in a compile
>> error due to mismatched signatures?
> I think one of the biggest problems is that ID resolution crosses file
> boundaries. This essentially means that the ids chosen can very easily become
> part of the "API" of a component unless you are very vigilant to not allow
> that to happen.
Yes, implicit ID resolution across file boundaries is something that
needs replacing with an explicit _interface_ declaration. I think that
we may agree on that goal?
> Essentially this means that identifiers - and a child redefining an
> identifier that the parent happened to use - suffer from the same problem
> that you point out class members can suffer from.
>
> This is a contrived example, but I have seen similar things to this cause
> bugs in production.
>
> Picture a SettingsButton.qml with this sort of contents:
> Button { MouseArea { onClicked: console.log("clicked"); } }
>
> Looks nice and innocent, right? But I notice that the MouseArea doesn't work
> because it has no geometry. I want to refer to it elsewhere in this
> component, too, so let's give it a name.
>
> Button { MouseArea { id: someFoo; width: parent.width; onClicked:
> console.log("clicked"); } }
>
> In sensible code, this would work just fine, and have no complications.
> Unfortunately, what you didn't know was that Button.qml is:
>
> Rectangle {
> width: someFoo.width
> height: 10
> }
>
> The use of someFoo here was previously referring to a parent id. Now, it
> finds that id in the child instead, with a very different geometry to what
> was expected - just the same as if this was a property on the root item.
>
> This is not an easy problem I think. For sure, you can't just take the "easy
> way" out and warn about duplicate ids during lookup, because while
> _sometimes_ this inheritance is decidedly wrong and not what you want, a lot
> of the time, id scoping is "private" and just fundamentally how code is
> written. In the C++ world, this would seem pretty silly:
>
> class Base { private: int m_myImplementationDetail; }
> class Base : Derived { private: int m_myImplementationDetail; } //
> warning: duplicate variable "m_myImplementationDetail" found in class Base
>
> Yes, they do indeed have the same name, but that's also unambiguous and fine.
>
> If we do consider them to be part of the API *sometimes* though, perhaps the
> right thing to do is to allow that to happen explicitly: specify what ids can
> be "exported/imported" and issue a compile error if those expectations are
> not met.
>
> One problem though is that this import/export boundary should be checked at
> the file boundary, _not_ the component boundary, otherwise using things like
> Loader become a lot more annoying.
>
> So perhaps it could look something like this:
>
> import MyModule ...
> expects Item myFoo; // we want something of type Item, identified as myFoo to
> be passed in from a containing file somewhere
> provides MouseArea bar; // we provide this ID for children to find
>
> Item {
> width: myFoo.width
>
> MouseArea {
> id: bar // is visible in scoped lookup (via 'provides' at the top)
> }
> }
>
> I guess you might also be able to use this for context properties - which
> suffer from many of the same unclear scoping issues rather than just outright
>
Re: [Development] QTCS2019 Notes from QtQml session
On 26/11/2019 09:34, Chris Adams wrote:
On Mon, Nov 25, 2019 at 9:34 PM Ulf Hermann wrote:
I think one of the biggest problems is that ID resolution crosses
file boundaries. This essentially means that the ids chosen can very
easily become part of the "API" of a component unless you are very
vigilant to not allow that to happen.
Well, yes, and there is an easy way to fix this: Deprecate id lookup
across file scope. id lookup is actually the same as context property
lookup right now. That's what you're seeing there. We cannot get rid of
IDs, obviously, but we can restrict their use to the file context and
not search the whole context hierarchy.
Could I suggest also changing the id syntax to clarify that id is not
an object attribute?
e.g.:
Button id: btn { }
or
Button is btn { }
or
Button as btn { }
are IMO better syntax than:
Button { id: btn }
as for the former they are clearer that the ids are attributes of the
component scope rather than attributes of the object per-se, which is
what is suggested by the latter.
I'd tend to agree with that one. Perhaps it could just be
Button btn { }
No "id:" "is" or "as" needed?
Still: huge change again going to affect lots of existing code...
André
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
thanks Elvis, Filippo, Ulf,
now I know what to do the next months to make my apps QML3 - ready ;-)
yes - then my code will be better re-usable and cleaner as now
will blog about all those refactorings
ciao
ekke
Am 26.11.19 um 09:20 schrieb Elvis Stansvik:
> Den mån 25 nov. 2019 kl 22:08 skrev Filippo Cucchetto
> :
>> @Ekke
>> I think you should redesign your qml the other way around. For your problem
>> there're multiple solutions
>> 1) Use some sort of StackView.view attached property. This is *usually*
>> implemented with a simple upward hierarchy lookup of the first instance of a
>> StackView.
>> In this way you get the reference of the StackView from leaf nodes.
>> 2) Pass a StackView reference to the Page at the point of instantiation
>> Page1 {
>>id: page1
>>view: stackView // used inside Page implementation
>> }
>> 3) JUST DO THE RIGHT THING. Your page qml should not have code that directly
>> calls the the StackView (This couples the Page to know that there's a
>> StackView).
>> Instead your page should just expose signals or items. The wiring between
>> these signals and view is done outside.
>> For example instead of:
>>
>> // Page1,qml
>> Item {
>> Button { onClicked: stackView.doSomething() } // Reference StackView by
>> id..magically...awful!!
>> }
>>
>> Do like this
>> // Page1.qml
>> Item {
>> property alias loginButton: button
>> Button { id: button }
>> }
>>
>> // Somewhere.qml
>>
>> Page1 {
>>loginButton.onClicked: stackview.doSomething() // Logic outside view
>> }
> I agree. An analog to this in Qt/C++ land would be doing something like
>
> auto foo = static_cast(parent());
> // Use foo
>
> in a child widget, which is certainly a code smell (making assumptions
> about the context).
>
> The changes suggested would hurt our code base a little, because I
> know we're guilty of this transgression in some places of our QML as
> well. But I think it's worth it and the changes needed would improve
> our code.
>
> Just my 2 cents.
>
> Elvis
>
>> This solution allows Page1 to be just a view (like an old .ui file).
>> In other words Page1 interface implies that there's a button or a clicked
>> signal but you're free to connect its
>> clicked signal to a StackView or SwipeView since wiring is done outside it.
>>
>> A even better solution is to delegate this to a FSM
>>
>> Page1 {
>> loginButton.onClicked: fsm.login()
>> }
>>
>> And then use a state of the FSM for handling the current page of the
>> StackView
>>
>> StackView {
>> currentPageComponent: {
>> if (fsm.loginState.active) {
>>return loginPageComponent
>> } else if (fsm.connectedState.active) {
>> return connectedState.Compononent
>> }
>> }
>> }
>>
>> Best regards,
>>
>> Filippo
>>
>>
>> Il giorno lun 25 nov 2019 alle ore 16:54 ekke ha
>> scritto:
>>> Am 25.11.19 um 15:53 schrieb Ulf Hermann:
> Yeah, that's going to make using QML in actual applications a whole lot
> harder. For instance, sometimes access to some root node is needed even
> from deep leaf files. Removing that capability is quite a drastic measure.
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.
>>> h :(
>>>
>>> because of my own project rules my code is re-usable through all my projects
>>>
>>> from discussions here I learned to use SingletonInstance which can
>>> replace the properties I set in my root (main.qml)
>>>
>>> but there are many other situations where I thinkl this won't help
>>>
>>> per ex
>>>
>>> main.qml --> StackView --> Page1 --> Page2 --> Popup
>>>
>>> from main there are some StackViews (+ Pages) switchedby Drawer
>>>
>>> Page1 or Page2 can be used on top of different StackViews
>>>
>>> there are some properties and functions from StackView used by Pages or
>>> Popup. Can access them via id because all my StackViews have same id
>>>
>>> any idea how this should be refactored for QML 3 without loosing all the
>>> cool flexibility ?
>>>
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.
>>> of course my goal is to go to QML 3
>>>
>>> ekke
>>>
Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>>
>>
>> --
>> Filippo Cucchetto
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
___
Development
Re: [Development] QTCS2019 Notes from QtQml session
On Mon, Nov 25, 2019 at 9:34 PM Ulf Hermann wrote:
>
> > I think one of the biggest problems is that ID resolution crosses
> > file boundaries. This essentially means that the ids chosen can very
> > easily become part of the "API" of a component unless you are very
> > vigilant to not allow that to happen.
>
> Well, yes, and there is an easy way to fix this: Deprecate id lookup
> across file scope. id lookup is actually the same as context property
> lookup right now. That's what you're seeing there. We cannot get rid of
> IDs, obviously, but we can restrict their use to the file context and
> not search the whole context hierarchy.
Could I suggest also changing the id syntax to clarify that id is not
an object attribute?
e.g.:
Button id: btn { }
or
Button is btn { }
or
Button as btn { }
are IMO better syntax than:
Button { id: btn }
as for the former they are clearer that the ids are attributes of the
component scope rather than attributes of the object per-se, which is
what is suggested by the latter.
Cheers,
Chris.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Den mån 25 nov. 2019 kl 22:08 skrev Filippo Cucchetto
:
>
> @Ekke
> I think you should redesign your qml the other way around. For your problem
> there're multiple solutions
> 1) Use some sort of StackView.view attached property. This is *usually*
> implemented with a simple upward hierarchy lookup of the first instance of a
> StackView.
> In this way you get the reference of the StackView from leaf nodes.
> 2) Pass a StackView reference to the Page at the point of instantiation
> Page1 {
>id: page1
>view: stackView // used inside Page implementation
> }
> 3) JUST DO THE RIGHT THING. Your page qml should not have code that directly
> calls the the StackView (This couples the Page to know that there's a
> StackView).
> Instead your page should just expose signals or items. The wiring between
> these signals and view is done outside.
> For example instead of:
>
> // Page1,qml
> Item {
> Button { onClicked: stackView.doSomething() } // Reference StackView by
> id..magically...awful!!
> }
>
> Do like this
> // Page1.qml
> Item {
> property alias loginButton: button
> Button { id: button }
> }
>
> // Somewhere.qml
>
> Page1 {
>loginButton.onClicked: stackview.doSomething() // Logic outside view
> }
I agree. An analog to this in Qt/C++ land would be doing something like
auto foo = static_cast(parent());
// Use foo
in a child widget, which is certainly a code smell (making assumptions
about the context).
The changes suggested would hurt our code base a little, because I
know we're guilty of this transgression in some places of our QML as
well. But I think it's worth it and the changes needed would improve
our code.
Just my 2 cents.
Elvis
>
> This solution allows Page1 to be just a view (like an old .ui file).
> In other words Page1 interface implies that there's a button or a clicked
> signal but you're free to connect its
> clicked signal to a StackView or SwipeView since wiring is done outside it.
>
> A even better solution is to delegate this to a FSM
>
> Page1 {
> loginButton.onClicked: fsm.login()
> }
>
> And then use a state of the FSM for handling the current page of the StackView
>
> StackView {
> currentPageComponent: {
> if (fsm.loginState.active) {
>return loginPageComponent
> } else if (fsm.connectedState.active) {
> return connectedState.Compononent
> }
> }
> }
>
> Best regards,
>
> Filippo
>
>
> Il giorno lun 25 nov 2019 alle ore 16:54 ekke ha
> scritto:
>>
>> Am 25.11.19 um 15:53 schrieb Ulf Hermann:
>> >> Yeah, that's going to make using QML in actual applications a whole lot
>> >> harder. For instance, sometimes access to some root node is needed even
>> >> from deep leaf files. Removing that capability is quite a drastic measure.
>> > 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.
>>
>> h :(
>>
>> because of my own project rules my code is re-usable through all my projects
>>
>> from discussions here I learned to use SingletonInstance which can
>> replace the properties I set in my root (main.qml)
>>
>> but there are many other situations where I thinkl this won't help
>>
>> per ex
>>
>> main.qml --> StackView --> Page1 --> Page2 --> Popup
>>
>> from main there are some StackViews (+ Pages) switchedby Drawer
>>
>> Page1 or Page2 can be used on top of different StackViews
>>
>> there are some properties and functions from StackView used by Pages or
>> Popup. Can access them via id because all my StackViews have same id
>>
>> any idea how this should be refactored for QML 3 without loosing all the
>> cool flexibility ?
>>
>> >
>> > 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.
>>
>> of course my goal is to go to QML 3
>>
>> ekke
>>
>> >
>> > Ulf
>> > ___
>> > Development mailing list
>> > Development@qt-project.org
>> > https://lists.qt-project.org/listinfo/development
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>
>
>
> --
> Filippo Cucchetto
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
> We have some code that evaluates JS in custom QQmlContexts with certain
> "magic" context properties set (sort of like the "index" or "modelData"
> context properties in delegates like Repeater.delegate).
> Will something similar still be possible?
You should rephrase that as required properties on actual objects. Then
the magic won't work anymore and you'll have to look up the properties
by ID of the object, but that is a good thing. It will improve
re-usability of your components.
We're also changing the way views and delegate work. If you want to use
the "index" in a Repeater's delegate you'll have to declare that in QML
3, using a required property:
Repeater {
model: 10
Text {
required property int index
text: "item " + index
}
}
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 21/11/2019 09:17, Ulf Hermann wrote: > Context properties > -- > > These are remarkably evil and actually unnecessary. You can readily > replace them with singletons or object properties (possibly required > ones) already in 5.15. We can deprecate context properties. See also > QTBUG-73064 We have some code that evaluates JS in custom QQmlContexts with certain "magic" context properties set (sort of like the "index" or "modelData" context properties in delegates like Repeater.delegate). Will something similar still be possible? Regards, Arno -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.r...@menlosystems.com www.menlosystems.com Menlo Systems GmbH Am Klopferspitz 19a, 82152 Martinsried, Germany Amtsgericht München HRB 138145 Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr. DE217772017, St.-Nr. 14316170324 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Having followed the evolution and first announcement of Qml/Quick QML3
seems like an admission of guilt.
I remember when a lot of people complained about the use of Javascript as a
scripting language and further
more on the lack of a public C++ API. Now it seems like some of the QML
problems are going to be fixed
but still i wonder if instead of putting man power in cutting QML2 we could
bring first citizen C++ QtQuick API.
Playing the devil's advocate why can't we leave QML2 as is and instead use
the new pseudo declarative
C++ syntax and code everything in C++? I mean...we want speed? you want
speed? use plain C++.
Il giorno lun 25 nov 2019 alle ore 22:06 Filippo Cucchetto <
filippocucche...@gmail.com> ha scritto:
> @Ekke
> I think you should redesign your qml the other way around. For your
> problem there're multiple solutions
> 1) Use some sort of StackView.view attached property. This is *usually*
> implemented with a simple upward hierarchy lookup of the first instance of
> a StackView.
> In this way you get the reference of the StackView from leaf nodes.
> 2) Pass a StackView reference to the Page at the point of instantiation
> Page1 {
>id: page1
>view: stackView // used inside Page implementation
> }
> 3) JUST DO THE RIGHT THING. Your page qml should not have code that
> directly calls the the StackView (This couples the Page to know that
> there's a StackView).
> Instead your page should just expose signals or items. The wiring between
> these signals and view is done outside.
> For example instead of:
>
> // Page1,qml
> Item {
> Button { onClicked: stackView.doSomething() } // Reference StackView by
> id..magically...awful!!
> }
>
> Do like this
> // Page1.qml
> Item {
> property alias loginButton: button
> Button { id: button }
> }
>
> // Somewhere.qml
>
> Page1 {
>loginButton.onClicked: stackview.doSomething() // Logic outside view
> }
>
> This solution allows Page1 to be just a view (like an old .ui file).
> In other words Page1 interface implies that there's a button or a clicked
> signal but you're free to connect its
> clicked signal to a StackView or SwipeView since wiring is done outside it.
>
> A even better solution is to delegate this to a FSM
>
> Page1 {
> loginButton.onClicked: fsm.login()
> }
>
> And then use a state of the FSM for handling the current page of the
> StackView
>
> StackView {
> currentPageComponent: {
> if (fsm.loginState.active) {
>return loginPageComponent
> } else if (fsm.connectedState.active) {
> return connectedState.Compononent
> }
> }
> }
>
> Best regards,
>
> Filippo
>
>
> Il giorno lun 25 nov 2019 alle ore 16:54 ekke ha
> scritto:
>
>> Am 25.11.19 um 15:53 schrieb Ulf Hermann:
>> >> Yeah, that's going to make using QML in actual applications a whole
>> lot
>> >> harder. For instance, sometimes access to some root node is needed
>> even
>> >> from deep leaf files. Removing that capability is quite a drastic
>> measure.
>> > 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.
>>
>> h :(
>>
>> because of my own project rules my code is re-usable through all my
>> projects
>>
>> from discussions here I learned to use SingletonInstance which can
>> replace the properties I set in my root (main.qml)
>>
>> but there are many other situations where I thinkl this won't help
>>
>> per ex
>>
>> main.qml --> StackView --> Page1 --> Page2 --> Popup
>>
>> from main there are some StackViews (+ Pages) switchedby Drawer
>>
>> Page1 or Page2 can be used on top of different StackViews
>>
>> there are some properties and functions from StackView used by Pages or
>> Popup. Can access them via id because all my StackViews have same id
>>
>> any idea how this should be refactored for QML 3 without loosing all the
>> cool flexibility ?
>>
>> >
>> > 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.
>>
>> of course my goal is to go to QML 3
>>
>> ekke
>>
>> >
>> > Ulf
>> > ___
>> > Development mailing list
>> > Development@qt-project.org
>> > https://lists.qt-project.org/listinfo/development
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
>
> --
> Filippo Cucchetto
>
--
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
@Ekke
I think you should redesign your qml the other way around. For your problem
there're multiple solutions
1) Use some sort of StackView.view attached property. This is *usually*
implemented with a simple upward hierarchy lookup of the first instance of
a StackView.
In this way you get the reference of the StackView from leaf nodes.
2) Pass a StackView reference to the Page at the point of instantiation
Page1 {
id: page1
view: stackView // used inside Page implementation
}
3) JUST DO THE RIGHT THING. Your page qml should not have code that
directly calls the the StackView (This couples the Page to know that
there's a StackView).
Instead your page should just expose signals or items. The wiring between
these signals and view is done outside.
For example instead of:
// Page1,qml
Item {
Button { onClicked: stackView.doSomething() } // Reference StackView by
id..magically...awful!!
}
Do like this
// Page1.qml
Item {
property alias loginButton: button
Button { id: button }
}
// Somewhere.qml
Page1 {
loginButton.onClicked: stackview.doSomething() // Logic outside view
}
This solution allows Page1 to be just a view (like an old .ui file).
In other words Page1 interface implies that there's a button or a clicked
signal but you're free to connect its
clicked signal to a StackView or SwipeView since wiring is done outside it.
A even better solution is to delegate this to a FSM
Page1 {
loginButton.onClicked: fsm.login()
}
And then use a state of the FSM for handling the current page of the
StackView
StackView {
currentPageComponent: {
if (fsm.loginState.active) {
return loginPageComponent
} else if (fsm.connectedState.active) {
return connectedState.Compononent
}
}
}
Best regards,
Filippo
Il giorno lun 25 nov 2019 alle ore 16:54 ekke ha
scritto:
> Am 25.11.19 um 15:53 schrieb Ulf Hermann:
> >> Yeah, that's going to make using QML in actual applications a whole lot
> >> harder. For instance, sometimes access to some root node is needed even
> >> from deep leaf files. Removing that capability is quite a drastic
> measure.
> > 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.
>
> h :(
>
> because of my own project rules my code is re-usable through all my
> projects
>
> from discussions here I learned to use SingletonInstance which can
> replace the properties I set in my root (main.qml)
>
> but there are many other situations where I thinkl this won't help
>
> per ex
>
> main.qml --> StackView --> Page1 --> Page2 --> Popup
>
> from main there are some StackViews (+ Pages) switchedby Drawer
>
> Page1 or Page2 can be used on top of different StackViews
>
> there are some properties and functions from StackView used by Pages or
> Popup. Can access them via id because all my StackViews have same id
>
> any idea how this should be refactored for QML 3 without loosing all the
> cool flexibility ?
>
> >
> > 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.
>
> of course my goal is to go to QML 3
>
> ekke
>
> >
> > Ulf
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
--
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 25/11/2019 12:35, Ulf Hermann wrote: Add one of the "b" to QSomething and the user code silently stops working. It's an unfortunate consequence of shadowing; this is considered bad practice (e.g. ES.12). Would it help to have a warn-on-shadowing pragma? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On Mon, Nov 25, 2019, at 4:55 PM, Robin Burchell wrote: > The situation for QML3 seems to be much less clear cut (This got sent a bit too early (hotkey mixup). Pretend this was at the bottom of my last mail.) I can't really comment on all of this stuff individually, because I'd be writing an encyclopedia and I've already written a lot (and I've been trying to stay away from Qt for a while because I've been too busy and burned out to have the time or the patience to do anything here anyway), but this is important enough that I thought I'd at least try. I guess my thinking in general is: New things are good. Change is good. But both of these are only actually good if they are genuinely worth the pain that the transitioning involves. Change that involves touching every file (version numbers, removing anchors.left/font.bold), or rewriting code in one way to another (context properties to singletons) seems like something that is honestly not worth fixing unless there is a very clear gain that I'm unable to discern from it because it pointlessly adds pain onto your users, who in turn will add pain onto you by not performing a quick transition and forcing you to support the old stuff far longer than you'd reasonably want to. I think it would be much better to see more effort put into smoothing the transition - whether that's through automation/tooling, or a relaxed approach to deprecating these features - or something, at least for some amount of time, rather than just saying "tough luck, go run an obsolete version of QML". -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 11/25/19 4:55 PM, 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 did read your proposal. I'm not opposed to introducing new language constructs in order to facilitate easier porting from QML 2 to QML 3. However, in this particular case, the proposed syntax feels to me very much like the required properties syntax. If you need to specify both "expects" and "provides", I don't see the huge benefit over declaring a required property on the root item of a child component and setting that from the parent component. Granted, that might be clumsy if you have many such child components, but remember that we are also introducing inline components. Therefore, you could declare an inline component with the required propertiea set in one place and instantiate that in many places without repeating the property-setting stanza. This is not set in stone, though. If this is not good enough, we can introduce a different concept. Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
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. > 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Am 25.11.19 um 15:53 schrieb Ulf Hermann: >> Yeah, that's going to make using QML in actual applications a whole lot >> harder. For instance, sometimes access to some root node is needed even >> from deep leaf files. Removing that capability is quite a drastic measure. > 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. h :( because of my own project rules my code is re-usable through all my projects from discussions here I learned to use SingletonInstance which can replace the properties I set in my root (main.qml) but there are many other situations where I thinkl this won't help per ex main.qml --> StackView --> Page1 --> Page2 --> Popup from main there are some StackViews (+ Pages) switchedby Drawer Page1 or Page2 can be used on top of different StackViews there are some properties and functions from StackView used by Pages or Popup. Can access them via id because all my StackViews have same id any idea how this should be refactored for QML 3 without loosing all the cool flexibility ? > > 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. of course my goal is to go to QML 3 ekke > > Ulf > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 25-11-19 15:53, Ulf Hermann wrote: Yeah, that's going to make using QML in actual applications a whole lot harder. For instance, sometimes access to some root node is needed even from deep leaf files. Removing that capability is quite a drastic measure. 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. 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 will still work in QML 2" is not a great one if you want people to port over to QML 3. And you will need to support something like this anyway. So far, the feeling I'm getting is that you're quite rigorously axing things from QML 2 in QML 3 in order to clean up because it is "broken" in QML 2. But without careful consideration what should replace it, that will just lead to the same issues again or a less usable QML for real world applications. I'm a bit concerned. André ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
> Yeah, that's going to make using QML in actual applications a whole lot > harder. For instance, sometimes access to some root node is needed even > from deep leaf files. Removing that capability is quite a drastic measure. 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. 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. Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 25-11-19 12:31, Ulf Hermann wrote: I think one of the biggest problems is that ID resolution crosses file boundaries. This essentially means that the ids chosen can very easily become part of the "API" of a component unless you are very vigilant to not allow that to happen. Well, yes, and there is an easy way to fix this: Deprecate id lookup across file scope. id lookup is actually the same as context property lookup right now. That's what you're seeing there. We cannot get rid of IDs, obviously, but we can restrict their use to the file context and not search the whole context hierarchy. Yeah, that's going to make using QML in actual applications a whole lot harder. For instance, sometimes access to some root node is needed even from deep leaf files. Removing that capability is quite a drastic measure. André Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
> Il 25/11/19 10:25, Eike Ziller ha scritto:
>>> ?
>> Similar things can happen in C++ with method names.
>> C++ got the ‘override’ keyword to make these breakages detectable by
>> tooling.
>> It looks to me like the case id==propertyname would also be detectable
>> by tooling?
>
> What do you mean? Can you make an example? The whole point of shadowing
> in C++ is to make sure that the above does NOT break.
Consider QSomething to be Qt code and the rest user code:
class QSomething {
public:
//struct b {};
//void b() { qDebug() << Q_FUNC_INFO; }
};
void b() { qDebug() << Q_FUNC_INFO; }
class c : public QSomething {
public:
void x() { b(); }
};
int main(int argc, char *argv[])
{
c ttt;
ttt.x();
}
Add one of the "b" to QSomething and the user code silently stops working.
Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
> I think one of the biggest problems is that ID resolution crosses > file boundaries. This essentially means that the ids chosen can very > easily become part of the "API" of a component unless you are very > vigilant to not allow that to happen. Well, yes, and there is an easy way to fix this: Deprecate id lookup across file scope. id lookup is actually the same as context property lookup right now. That's what you're seeing there. We cannot get rid of IDs, obviously, but we can restrict their use to the file context and not search the whole context hierarchy. Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
> On 25. Nov 2019, at 11:03, Giuseppe D'Angelo via Development
> wrote:
>
> Il 25/11/19 10:25, Eike Ziller ha scritto:
>>> ?
>> Similar things can happen in C++ with method names.
>> C++ got the ‘override’ keyword to make these breakages detectable by tooling.
>> It looks to me like the case id==propertyname would also be detectable by
>> tooling?
>
> What do you mean? Can you make an example? The whole point of shadowing in
> C++ is to make sure that the above does NOT break.
Funny things can happen if the new method in the base class is virtual.
// in library libA
class A {
};
// in user code
class B {
public:
void foo();
};
now class A changes to
class A {
public:
virtual void foo();
};
Code in libA now calls “foo” on instances of subclasses of A, including
instances of B, with funny results.
I vaguely remember that we had a case of that in Qt Creator where Qt introduced
some method in one of its classes.
--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On Mon, Nov 25, 2019, at 10:43 AM, Ulf Hermann wrote:
> Indeed we need to deal with this somehow. Maybe we do need to retain
> versioning on a module level. For example, the qmldir file could specify
> what versions of which other modules it expects. Or we define that it's
> not a problem ...
I think at least module-level versioning is a sensible idea.
> We could detect this in qmllint by just continuing the search for IDs
> even if we've found a property.
We could, but if I may gently suggest, I think I can count most of the people
who use qmllint on a regular, useful basis on one hand ;-).
(One possible improvement to this could be to not _just_ have it as a separate
tool: maybe debug builds should _also_ run qmllint - or at least a subset of
its checks - on the code that the engine is loading? Alternatively, perhaps as
an engine flag to at least allow it to be turned on once, and happen for
everyone on a team in a unified zero-effort way)
> Mind that adding a method to a base class in C++ will shadow unrelated
> other classes and functions even if it's not virtual or overridden. Why
> did we actually decide that we can live with this effect in C++ but not
> in QML? - Maybe because in C++ it's more likely to result in a compile
> error due to mismatched signatures?
I think one of the biggest problems is that ID resolution crosses file
boundaries. This essentially means that the ids chosen can very easily become
part of the "API" of a component unless you are very vigilant to not allow that
to happen.
Essentially this means that identifiers - and a child redefining an identifier
that the parent happened to use - suffer from the same problem that you point
out class members can suffer from.
This is a contrived example, but I have seen similar things to this cause bugs
in production.
Picture a SettingsButton.qml with this sort of contents:
Button { MouseArea { onClicked: console.log("clicked"); } }
Looks nice and innocent, right? But I notice that the MouseArea doesn't work
because it has no geometry. I want to refer to it elsewhere in this component,
too, so let's give it a name.
Button { MouseArea { id: someFoo; width: parent.width; onClicked:
console.log("clicked"); } }
In sensible code, this would work just fine, and have no complications.
Unfortunately, what you didn't know was that Button.qml is:
Rectangle {
width: someFoo.width
height: 10
}
The use of someFoo here was previously referring to a parent id. Now, it finds
that id in the child instead, with a very different geometry to what was
expected - just the same as if this was a property on the root item.
This is not an easy problem I think. For sure, you can't just take the "easy
way" out and warn about duplicate ids during lookup, because while _sometimes_
this inheritance is decidedly wrong and not what you want, a lot of the time,
id scoping is "private" and just fundamentally how code is written. In the C++
world, this would seem pretty silly:
class Base { private: int m_myImplementationDetail; }
class Base : Derived { private: int m_myImplementationDetail; } // warning:
duplicate variable "m_myImplementationDetail" found in class Base
Yes, they do indeed have the same name, but that's also unambiguous and fine.
If we do consider them to be part of the API *sometimes* though, perhaps the
right thing to do is to allow that to happen explicitly: specify what ids can
be "exported/imported" and issue a compile error if those expectations are not
met.
One problem though is that this import/export boundary should be checked at the
file boundary, _not_ the component boundary, otherwise using things like Loader
become a lot more annoying.
So perhaps it could look something like this:
import MyModule ...
expects Item myFoo; // we want something of type Item, identified as myFoo to
be passed in from a containing file somewhere
provides MouseArea bar; // we provide this ID for children to find
Item {
width: myFoo.width
MouseArea {
id: bar // is visible in scoped lookup (via 'provides' at the top)
}
}
I guess you might also be able to use this for context properties - which
suffer from many of the same unclear scoping issues rather than just outright
removing them, but that might require some additional considerations that I'm
not sure of right now.
--
Robin Burchell
ro...@crimson.no
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Il 25/11/19 10:25, Eike Ziller ha scritto: ? Similar things can happen in C++ with method names. C++ got the ‘override’ keyword to make these breakages detectable by tooling. It looks to me like the case id==propertyname would also be detectable by tooling? What do you mean? Can you make an example? The whole point of shadowing in C++ is to make sure that the above does NOT break. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
>> While I agree with this overall, there's still one caveat which I
>> haven't seen discussed yet:
>>
>> Imagine I have the following code:
>>
>> Item { id: foo property color prettyColor: "#f0f"
>>
>> Rectangle { color: foo.prettyColor } }
>>
>> Right now "foo" refers to the Item. What if in a future update,
>> Rectangle gains a new property "foo". Unless you want to force
>> everyone to be explicit by using "this" (e.g. width: this.height)
>> everywhere, which would be annoying, I don't see how this can be
>> made future-proof without some form of versioning or some other
>> magic solution?
Indeed we need to deal with this somehow. Maybe we do need to retain
versioning on a module level. For example, the qmldir file could specify
what versions of which other modules it expects. Or we define that it's
not a problem ...
> Similar things can happen in C++ with method names. C++ got the
> ‘override’ keyword to make these breakages detectable by tooling. It
> looks to me like the case id==propertyname would also be detectable
> by tooling?
We could detect this in qmllint by just continuing the search for IDs
even if we've found a property.
Mind that adding a method to a base class in C++ will shadow unrelated
other classes and functions even if it's not virtual or overridden. Why
did we actually decide that we can live with this effect in C++ but not
in QML? - Maybe because in C++ it's more likely to result in a compile
error due to mismatched signatures?
Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
> On 22. Nov 2019, at 11:52, Kai Uwe Broulik wrote:
>
> Hi,
>
> > these are the notes on the QtQml session:
>
> > Versioning
> > --
> >
> > Once we get rid of unqualified lookups we don't need any QML versioning
> > anymore. At least the minor version will become optional already in 5.15
> > for well-behaved QML documents. In QML 3 it won't be allowed.
>
> While I agree with this overall, there's still one caveat which I haven't
> seen discussed yet:
>
> Imagine I have the following code:
>
> Item {
>id: foo
>property color prettyColor: "#f0f"
>
>Rectangle {
>color: foo.prettyColor
>}
> }
>
> Right now "foo" refers to the Item. What if in a future update, Rectangle
> gains a new property "foo". Unless you want to force everyone to be explicit
> by using "this" (e.g. width: this.height) everywhere, which would be
> annoying, I don't see how this can be made future-proof without some form of
> versioning or some other magic solution?
Similar things can happen in C++ with method names.
C++ got the ‘override’ keyword to make these breakages detectable by tooling.
It looks to me like the case id==propertyname would also be detectable by
tooling?
Br, Eike
--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Hello Giuseppe,
>> qmlRegisterSingletonInstance("Utils", 3, 14, "Obj", obj);
>In 5.14 the solution is something along the lines of
Exactly what I was looking for.
>In pre-5.14 the same is achieved by using qmlRegisterSingletonType with
>a callback (that returns the object + sets the ownership of the object
>to C++; definitely not as convenient). Usage from QML is identical.
I was using context properties and were not that in-depth with the singletons.
I did read the great Qt documentation on them, maybe I have missed that.
Thanks for pointing it out.
On Fri, Nov 22, 2019 at 7:14 PM Giuseppe D'Angelo via Development
wrote:
>
> Il 22/11/19 16:49, Damian Ivanov ha scritto:
> > I don't see this anywhere documented how this could be done using a
> > singleton.
>
> In 5.14 the solution is something along the lines of
>
> > qmlRegisterSingletonInstance("Utils", 3, 14, "Obj", obj);
>
> then in QML
>
> > import Utils 3.14
> > // use "Obj" instead of "obj"
>
> In pre-5.14 the same is achieved by using qmlRegisterSingletonType with
> a callback (that returns the object + sets the ownership of the object
> to C++; definitely not as convenient). Usage from QML is identical.
>
>
> > If I register it as singleton the application_engine doesn't find it
> > findChild->
>
> Could you please elaborate on this point?
>
>
> Thanks,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Il 22/11/19 16:49, Damian Ivanov ha scritto:
I don't see this anywhere documented how this could be done using a singleton.
In 5.14 the solution is something along the lines of
qmlRegisterSingletonInstance("Utils", 3, 14, "Obj", obj);
then in QML
import Utils 3.14
// use "Obj" instead of "obj"
In pre-5.14 the same is achieved by using qmlRegisterSingletonType with
a callback (that returns the object + sets the ownership of the object
to C++; definitely not as convenient). Usage from QML is identical.
If I register it as singleton the application_engine doesn't find it
findChild->
Could you please elaborate on this point?
Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Additionally
https://forum.qt.io/topic/54353/solved-access-qml-singleton-object-from-c-code/4
seems also like a viable solution
though a syntax where qmlRegisterSingletonType return value is a
QObject would be very ease to read / write.
On Fri, Nov 22, 2019 at 6:33 PM Damian Ivanov wrote:
>
> Hi Dmitriy,
>
> Well I can't seem to find an easy example but an easy example:
> Instantiating a .qml with QQmlComponent::create which is of Window (I
> do this for others as well) type
> from c++ than I set obj->properties from c++ based on various events.
> Creating a singleton class seems like adding 30 lines of code per
> object in contrast to setContextProperty()
> Something like this would be nice if possible:
> QQmlComponent* m_component = new
> QQmlComponent(application_engine, "qrc:/Component.qml");
> QObject* m_obj ;
> qmlRegisterSingletonType("Component", 1, 0, "Identifier",
> [=]
> {
> m_obj = m_component->create();
> return m_obj;
> });
>
> On Fri, Nov 22, 2019 at 6:22 PM Dmitriy Purgin wrote:
> >
> > Hi Damian,
> >
> > that seems to be an interesting case. Could you provide an example of why
> > would you need such a pattern?
> >
> > Why the other way round -- creating a C++ singleton and exposing it to QML
> > -- doesn't work for you? That should be easier and more transparent.
> >
> > Cheers
> > Dmitriy
> >
> > On Fri, Nov 22, 2019 at 4:50 PM Damian Ivanov
> > wrote:
> >>
> >> How would .qml files that are singletons and instantiated from c++ be used
> >> currently I do this and am able to access it from qml and c++
> >> QQmlComponent* component = new QQmlComponent(application_engine,
> >> "qrc:/Component.qml");
> >> QObject* obj = component->create();
> >> obj->setParent(this);
> >> application_engine->rootContext()->setContextProperty("obj", obj);
> >>
> >> I don't see this anywhere documented how this could be done using a
> >> singleton.
> >> If I register it as singleton the application_engine doesn't find it
> >> findChild->
> >> Using component->create would create it again since it is already
> >> registered as a singleton.
> >>
> >> Any suggestions?
> >>
> >>
> >> ;
> >>
> >> On Fri, Nov 22, 2019 at 12:53 PM Kai Uwe Broulik
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > > these are the notes on the QtQml session:
> >> >
> >> > > Versioning
> >> > > --
> >> > >
> >> > > Once we get rid of unqualified lookups we don't need any QML
> >> > versioning
> >> > > anymore. At least the minor version will become optional already in
> >> > 5.15
> >> > > for well-behaved QML documents. In QML 3 it won't be allowed.
> >> >
> >> > While I agree with this overall, there's still one caveat which I
> >> > haven't seen discussed yet:
> >> >
> >> > Imagine I have the following code:
> >> >
> >> > Item {
> >> > id: foo
> >> > property color prettyColor: "#f0f"
> >> >
> >> > Rectangle {
> >> > color: foo.prettyColor
> >> > }
> >> > }
> >> >
> >> > Right now "foo" refers to the Item. What if in a future update,
> >> > Rectangle gains a new property "foo". Unless you want to force everyone
> >> > to be explicit by using "this" (e.g. width: this.height) everywhere,
> >> > which would be annoying, I don't see how this can be made future-proof
> >> > without some form of versioning or some other magic solution?
> >> >
> >> > Cheers
> >> > Kai Uwe
> >> > ___
> >> > Development mailing list
> >> > Development@qt-project.org
> >> > https://lists.qt-project.org/listinfo/development
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Hi Dmitriy,
Well I can't seem to find an easy example but an easy example:
Instantiating a .qml with QQmlComponent::create which is of Window (I
do this for others as well) type
from c++ than I set obj->properties from c++ based on various events.
Creating a singleton class seems like adding 30 lines of code per
object in contrast to setContextProperty()
Something like this would be nice if possible:
QQmlComponent* m_component = new
QQmlComponent(application_engine, "qrc:/Component.qml");
QObject* m_obj ;
qmlRegisterSingletonType("Component", 1, 0, "Identifier", [=]
{
m_obj = m_component->create();
return m_obj;
});
On Fri, Nov 22, 2019 at 6:22 PM Dmitriy Purgin wrote:
>
> Hi Damian,
>
> that seems to be an interesting case. Could you provide an example of why
> would you need such a pattern?
>
> Why the other way round -- creating a C++ singleton and exposing it to QML --
> doesn't work for you? That should be easier and more transparent.
>
> Cheers
> Dmitriy
>
> On Fri, Nov 22, 2019 at 4:50 PM Damian Ivanov wrote:
>>
>> How would .qml files that are singletons and instantiated from c++ be used
>> currently I do this and am able to access it from qml and c++
>> QQmlComponent* component = new QQmlComponent(application_engine,
>> "qrc:/Component.qml");
>> QObject* obj = component->create();
>> obj->setParent(this);
>> application_engine->rootContext()->setContextProperty("obj", obj);
>>
>> I don't see this anywhere documented how this could be done using a
>> singleton.
>> If I register it as singleton the application_engine doesn't find it
>> findChild->
>> Using component->create would create it again since it is already
>> registered as a singleton.
>>
>> Any suggestions?
>>
>>
>> ;
>>
>> On Fri, Nov 22, 2019 at 12:53 PM Kai Uwe Broulik
>> wrote:
>> >
>> > Hi,
>> >
>> > > these are the notes on the QtQml session:
>> >
>> > > Versioning
>> > > --
>> > >
>> > > Once we get rid of unqualified lookups we don't need any QML versioning
>> > > anymore. At least the minor version will become optional already in 5.15
>> > > for well-behaved QML documents. In QML 3 it won't be allowed.
>> >
>> > While I agree with this overall, there's still one caveat which I
>> > haven't seen discussed yet:
>> >
>> > Imagine I have the following code:
>> >
>> > Item {
>> > id: foo
>> > property color prettyColor: "#f0f"
>> >
>> > Rectangle {
>> > color: foo.prettyColor
>> > }
>> > }
>> >
>> > Right now "foo" refers to the Item. What if in a future update,
>> > Rectangle gains a new property "foo". Unless you want to force everyone
>> > to be explicit by using "this" (e.g. width: this.height) everywhere,
>> > which would be annoying, I don't see how this can be made future-proof
>> > without some form of versioning or some other magic solution?
>> >
>> > Cheers
>> > Kai Uwe
>> > ___
>> > Development mailing list
>> > Development@qt-project.org
>> > https://lists.qt-project.org/listinfo/development
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Hi Damian,
that seems to be an interesting case. Could you provide an example of why
would you need such a pattern?
Why the other way round -- creating a C++ singleton and exposing it to QML
-- doesn't work for you? That should be easier and more transparent.
Cheers
Dmitriy
On Fri, Nov 22, 2019 at 4:50 PM Damian Ivanov
wrote:
> How would .qml files that are singletons and instantiated from c++ be used
> currently I do this and am able to access it from qml and c++
> QQmlComponent* component = new QQmlComponent(application_engine,
> "qrc:/Component.qml");
> QObject* obj = component->create();
> obj->setParent(this);
> application_engine->rootContext()->setContextProperty("obj", obj);
>
> I don't see this anywhere documented how this could be done using a
> singleton.
> If I register it as singleton the application_engine doesn't find it
> findChild->
> Using component->create would create it again since it is already
> registered as a singleton.
>
> Any suggestions?
>
>
> ;
>
> On Fri, Nov 22, 2019 at 12:53 PM Kai Uwe Broulik
> wrote:
> >
> > Hi,
> >
> > > these are the notes on the QtQml session:
> >
> > > Versioning
> > > --
> > >
> > > Once we get rid of unqualified lookups we don't need any QML
> versioning
> > > anymore. At least the minor version will become optional already in
> 5.15
> > > for well-behaved QML documents. In QML 3 it won't be allowed.
> >
> > While I agree with this overall, there's still one caveat which I
> > haven't seen discussed yet:
> >
> > Imagine I have the following code:
> >
> > Item {
> > id: foo
> > property color prettyColor: "#f0f"
> >
> > Rectangle {
> > color: foo.prettyColor
> > }
> > }
> >
> > Right now "foo" refers to the Item. What if in a future update,
> > Rectangle gains a new property "foo". Unless you want to force everyone
> > to be explicit by using "this" (e.g. width: this.height) everywhere,
> > which would be annoying, I don't see how this can be made future-proof
> > without some form of versioning or some other magic solution?
> >
> > Cheers
> > Kai Uwe
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
How would .qml files that are singletons and instantiated from c++ be used
currently I do this and am able to access it from qml and c++
QQmlComponent* component = new QQmlComponent(application_engine,
"qrc:/Component.qml");
QObject* obj = component->create();
obj->setParent(this);
application_engine->rootContext()->setContextProperty("obj", obj);
I don't see this anywhere documented how this could be done using a singleton.
If I register it as singleton the application_engine doesn't find it
findChild->
Using component->create would create it again since it is already
registered as a singleton.
Any suggestions?
;
On Fri, Nov 22, 2019 at 12:53 PM Kai Uwe Broulik wrote:
>
> Hi,
>
> > these are the notes on the QtQml session:
>
> > Versioning
> > --
> >
> > Once we get rid of unqualified lookups we don't need any QML versioning
> > anymore. At least the minor version will become optional already in 5.15
> > for well-behaved QML documents. In QML 3 it won't be allowed.
>
> While I agree with this overall, there's still one caveat which I
> haven't seen discussed yet:
>
> Imagine I have the following code:
>
> Item {
> id: foo
> property color prettyColor: "#f0f"
>
> Rectangle {
> color: foo.prettyColor
> }
> }
>
> Right now "foo" refers to the Item. What if in a future update,
> Rectangle gains a new property "foo". Unless you want to force everyone
> to be explicit by using "this" (e.g. width: this.height) everywhere,
> which would be annoying, I don't see how this can be made future-proof
> without some form of versioning or some other magic solution?
>
> Cheers
> Kai Uwe
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Hi,
> these are the notes on the QtQml session:
> Versioning
> --
>
> Once we get rid of unqualified lookups we don't need any QML versioning
> anymore. At least the minor version will become optional already in 5.15
> for well-behaved QML documents. In QML 3 it won't be allowed.
While I agree with this overall, there's still one caveat which I
haven't seen discussed yet:
Imagine I have the following code:
Item {
id: foo
property color prettyColor: "#f0f"
Rectangle {
color: foo.prettyColor
}
}
Right now "foo" refers to the Item. What if in a future update,
Rectangle gains a new property "foo". Unless you want to force everyone
to be explicit by using "this" (e.g. width: this.height) everywhere,
which would be annoying, I don't see how this can be made future-proof
without some form of versioning or some other magic solution?
Cheers
Kai Uwe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Hi Ulf, thanks for clarifying. You're absolutely right, no other language supports importing different versions of dependencies but I think it is a great feature of QML that helps a lot in maintaining the old code. Would be sad to see it gone in QML 3. Cheers PS I'm forwarding this email to the mailing list again, apparently I didn't manage to this right in the first place On Thu, Nov 21, 2019 at 4:23 PM Ulf Hermann wrote: > > Suppose it's been a while, and your customer has used this library in > > their code in 100 QML files. Now you enhance/refactor your library and > > you decide that the name `popupSource` was not really good because it > > clashes with a new component, so you change it to `componentSource` in > > the new version: > > This is a compatibility breaking change. There is no way a QML program > written against the old version of your library will work with the new > version of your library without modification. You should use a new major > version for this. The minor versions were intended for non-breaking > changes, specifically for adding properties, methods, enums. If you > avoid unqualified lookup you can do these things without special > consideration in the customers of your library, as they won't see the > new constructs unless they explicitly look them up. > > We might also remove the major version, though. The cleanest way to > upgrade your library's clients to a new version of your library is not > providing both versions of the QML code in one version of your library, > but rather releasing a completely new library with only new code, and > adapting your client code to use that. Currently you can do that on a > file-by-file basis, but allowing that was a mistake. You should port the > client code at least on a module-by-module basis, so that you can use > the same version of your dependencies in each file. No other language I > know allows you to import different versions of a dependency in two > files of the same module. > > You may need some migration strategy, like providing deprecated > properties for a while in order to ease transition. This is pretty much > the same as in C++, then. > > Ulf > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QTCS2019 Notes from QtQml session
Hi,
these are the notes on the QtQml session:
Grouped properties
--
Grouped properties are incredibly buggy and basically unusable for
anything but font and anchors right now. The language would be better
off without the concept, allowing only the replacement of the full
object (e.g., hypothetically, with inline components: "font: MyText.Font
{ bold: true }") rather than individual grouped properties. The
semantics of such would be easier to understand and easier to implement,
but people don't like this, of course. See also QTBUG-72164
Context properties
--
These are remarkably evil and actually unnecessary. You can readily
replace them with singletons or object properties (possibly required
ones) already in 5.15. We can deprecate context properties. See also
QTBUG-73064
Versioning
--
Once we get rid of unqualified lookups we don't need any QML versioning
anymore. At least the minor version will become optional already in 5.15
for well-behaved QML documents. In QML 3 it won't be allowed.
Warnings / Transition to QML 3
--
We need a way of fine tuning the warnings. If you intend to port your
program to QML 3 you want to see all deprecation warnings. If not, you
want to suppress them all. If you want to stay with QML 2 but still fix
some of the more glaring problems in your code, you may want to enable
some warnings, but not others. We can have pragmas declaring what your
code aims for in the QML files themselves and environment variables to
switch warnings on or off. (In fact we want logging categories, but we
didn't talk about that). We're not going to add replacement
functionality (e.g. required properties) to 5.12 anymore. The base for
porting to QML 3 has to be Qt 5.15.
Smart pointer support
-
We want QML to properly deal with smart pointers. For example, it should
be possible to transfer ownership by moving a unique pointer. See also
QTBUG-60136
Sequence types
--
We need a way to register your own container classes with the QML engine
so that they behave the same way as certain auto-registered lists and
vectors do. See also QTBUG-71574. Also, people would like something akin
to QQmlListProperty in qtbase. That is, a lightweight "model" that just
grants access to some sequence data without providing storage for it.
Typed Model Data
We brainstormed a bit about how a model could declare its items' data
type in QML, so that we could statically check model against delegate
types. We will need this when compiling QML 3 to C++. We didn't come up
with anything really great, though. This needs more work.
Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
