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] QtCS19 Serialization session
On Monday, 25 November 2019 13:59:28 PST Arnaud Clère wrote:
> Hi Thiago,
>
> Regarding the last part:
> - it is frequent to have to save/load our types and then send/receive
> them to some server/device using,
> say QSettings/QJsonDocument for the first and JSON/CBOR for the latter
How many do so interchangeably. I'm not asking about whether we should support
different serialisations. I am asking how many types would benefit from a
single, standardised mechanism for multiple backends?
For example, a Rectangle in CBOR might be stored as (x1,y1,x2,y2) whereas the
QSettings format might have been XxY+W+H, which means a generic solution will
not work.
> - taking all Qt users into account, types like QList, QPoint are
> serialized to much more formats than we
> can imagine, so defining a zap method working the same way for
> QSettings, JSON, ... and also
> QAbstractItemModel, QQmlPropertyMap/List seems very useful to me.
> There are not much alternatives
> in how to serialize QList and the ones in CBOR are covered
> (definite/indefinite). QPoint::zap or, say,
> QColor::zap may not fit all use cases but the API allows to easily
> define another serialization.
I do not agree. Please back up that statement with data: how many types would
benefit from a standardised serialisation? And why are you including item
models in this, what do they have to do with serialisation?
> Now I guess the first part is more of a concern to you and I know the
> proposal do seem strange but hey,
> I used to understand assembly and now it looks strange to me!
Ok, that's actually a good point: assembly is very different from Qt-style
C++, but it's not usually mixed with C++. What you're proposing is a very,
very different API style that matches nothing in Qt and is meant to be used
alongside Qt-style C++.
> One reason for the weirdness is abstraction but how do you gain a lot
> of flexibility without raising the
> abstraction level a little (think iterators...)? The abstractions
> themselves are familiar though:
> - record=struct=object=QMap=QAssociativeIterable=...
> - sequence=iterator=array=list=QSequentialIterable=...
>
> Also, the fluent interface is just a little bit more elaborate version
> of QDataStream's fluent interface :
>
> QDataStream Person::operator<<(...) {
> return out
> << person.name
> << person.children; } // calling QList << then Person <<
>
> QValueStatus Person::zap(...) {
> return value.sequence()
> .item(person.name)
> .item(person.children); } // calling QList zap then Person zap
There is no example of fluent-like API in Qt. The closest we'll see of it in
C++ is the ranges API with operator|, which are meant to imitate a shell
pipeline anyway.
As I said, I don't like it and I fear a very different API could be confusing.
> Each method of the fluent interface will:
> 1. if the stream is valid and data matches the expected
> sequence/record/bool/... : consume the data and set referenced
> argument
> 2. else : do not move and report an error
> and so on with the next fluent interface call...
I understand what it's meant to do. I am saying I don't like that it does all
it does.
It's also advising people to write inefficient code. For example, de-
serialising a record requires repeated iterations and is either O(n log n) for
sorted records (like JSON) or O(n²) for unsorted ones like CBOR. In
value.record()
.item("a", a)
.item("b", b)
.item("c", c);
The .item() functions need to scan the QCborMap or QJsonObject container for
the values being searched, which is O(n) and O(log n) respectively. A more
efficient implementation would iterate over the keys, which is O(1).
> What do you guys think? Does it seem so un-Qtish as to bury or burn
> it? How can it be improved?
I don't know. I think there's value in having something, even if inefficient,
since it allows for ensuring every type *can* be serialised, whether it has a
better way of doing so or not. But there are other ways of accomplishing the
same, like providing either a JSON serialisation or a CBOR one, which can be
transported (however inefficiently) over other formats.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS19 Serialization session
-Original Message-
From: Thiago Macieira
>
> My point is that I can see the value in providing a single method whereby our
> and users' types
> can provide a descriptive format for their serialisation, regardless what the
> serialisation backend is.
> That way, a single method could be used for XML, JSON, CBOR, DataStream,
> Future Whatchanameit.
>
> However, the API is very un-Qtish. I don't like reading a method and not
> knowing what it does.
> You can only know what the zap() methods do in context of the parameter
> passed.
>
> One more thing: how often do the same types need serialisation to multiple
> formats in a way
> that can be done generically?
Hi Thiago,
Regarding the last part:
- it is frequent to have to save/load our types and then send/receive
them to some server/device using,
say QSettings/QJsonDocument for the first and JSON/CBOR for the latter
- taking all Qt users into account, types like QList, QPoint are
serialized to much more formats than we
can imagine, so defining a zap method working the same way for
QSettings, JSON, ... and also
QAbstractItemModel, QQmlPropertyMap/List seems very useful to me.
There are not much alternatives
in how to serialize QList and the ones in CBOR are covered
(definite/indefinite). QPoint::zap or, say,
QColor::zap may not fit all use cases but the API allows to easily
define another serialization.
Now I guess the first part is more of a concern to you and I know the
proposal do seem strange but hey,
I used to understand assembly and now it looks strange to me!
One reason for the weirdness is abstraction but how do you gain a lot
of flexibility without raising the
abstraction level a little (think iterators...)? The abstractions
themselves are familiar though:
- record=struct=object=QMap=QAssociativeIterable=...
- sequence=iterator=array=list=QSequentialIterable=...
Also, the fluent interface is just a little bit more elaborate version
of QDataStream's fluent interface :
QDataStream Person::operator<<(...) {
return out
<< person.name
<< person.children; } // calling QList << then Person <<
QValueStatus Person::zap(...) {
return value.sequence()
.item(person.name)
.item(person.children); } // calling QList zap then Person zap
Lastly, I think users will usually be more than API to use something
that just works and not have to dive
into specific APIs of QCbor* or QAbstractItemModel. But sure, as with
>>, they should be able to
understand what the API does, so let me try to explain it with has
little words as possible:
Each method of the fluent interface will:
1. if the stream is valid and data matches the expected
sequence/record/bool/... : consume the data and set referenced
argument
2. else : do not move and report an error
and so on with the next fluent interface call...
Not so much magic after all... However, being able to do #2 is what
makes it much more interesting
than QDataStream >> to me.
What do you guys think? Does it seem so un-Qtish as to bury or burn
it? How can it be improved?
Arnaud
___
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] RFC: QVariant changes in Qt6
On Sunday, 24 November 2019 13:02:32 PST Olivier Goffart wrote: > > OMG, are you really sure about these massive changes? > > Not 100% sure, no. > What specific changes are you worried about? > In this case, I believe the changes should lead to only small behavior > changes which are in fact fixes. > But this is of course up to discussion. > As always, it is a trade-of between stability but stagnation, or evolution. Indeed, one of the things we discussed was to freeze QVariant as an API, with its defects as they are, and introduce a new QAny class to have the behaviour we do want in the future. But we felt this would cause more confusion. It's difficult to make a decision without hard data. I think we need to attempt and try to run some representative sample of Qt-based code, to see what breaks. If too much does, we may need to back out and try the alternative (where "too much" will also need to be decided). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] RFC: QVariant changes in Qt6
On Sunday, 24 November 2019 09:57:56 PST Olivier Goffart wrote: > Adding a cast function does not sound like a bad idea? But should it be > done in Qt5.15 or Qt6. And should it return T or optional (in case the > conversion did not work) or have a bool*ok=nullptr parameter? The problem with std::optional in Qt 5 is that you can't require it. So either you add an API behind #if (which is ok) or you have to wait for Qt 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] RFC: QVariant changes in Qt6
On Monday, 25 November 2019 06:35:53 PST Giuseppe D'Angelo via Development wrote: > Il 24/11/19 18:57, Olivier Goffart ha scritto: > > The issue is that there is lots of use of these (esp. the most common ones > > like toString and toInt.) Removing all uses be a huge work for no obvious > > reasons. (And i was told they are now recommended by clazy) > > The reason was avoiding the template bloat of the instantiations of > value in client code, while such instantiations exist already in > QtCore under a "different form" -- if T is int, QString, etc. then > there's toInt(), toString() and so on. (I'm not sure of the overall > impact, though.) > > If we can use extern templates for the same purpose, then we could drop > the clazy warning for Qt 6, keep the toFoo() as porting aids and just > make them inline calls to value(). Those functions are really small and not worth the trouble of deduplicating. They'll likely be inlined anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS19 Notes: Qt 6 Network Overview
On Monday, 25 November 2019 11:23:55 PST Jason H wrote:
> If Qt removes QFTP, could Qt provide a "scp" implementation? Maybe
> regardless of QFTP, scp would still be a "Good Thing(tm)".
Very unlikely. I truly don't see anyone working on it. It might be rejected
even if it was supplied in a contribution.
> Ideally, this
> would be transparently supported in QUrls too: image.source =
> "scp://server/file.png" I can't seem to find a consolidated list of url
> schemes that Qt supports? QNAM::supportedSchemes gives: ("ftp", "file",
> "qrc", "http", "https", "data")
That is the correct list. We're discussing removing "ftp" from it and see who
will complain.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
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] QtCS19 Notes: Qt 6 Network Overview
> - Removing QFTP
> ○ This is about QFTP backend in QNetworkAccessManager
> ○ There are still public users, but how many?
> ○ Proposal: Disable it in 6.0 and check for amount of complaints
> § If limited (as expected) remove in 6.2 completely
If Qt removes QFTP, could Qt provide a "scp" implementation? Maybe regardless
of QFTP, scp would still be a "Good Thing(tm)".
Ideally, this would be transparently supported in QUrls too: image.source =
"scp://server/file.png"
I can't seem to find a consolidated list of url schemes that Qt supports?
QNAM::supportedSchemes gives: ("ftp", "file", "qrc", "http", "https", "data")
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
On Sun, Nov 24, 2019 at 09:48:46PM -0800, Thiago Macieira wrote: > On Sunday, 24 November 2019 00:50:14 PST André Pönitz wrote: > > Regarding the risk of "introduce subtle bugs by truncating sizes": That risk > > _is_ there in general for some of the proposed porting strategies, but not > > for the case of using a 32bit count(): We can assume that an existing > > application using QContainers is fine with 32bit, otherwise it wouldn't > > work right now. So continuing using 32bit interfaces does not introduce > > bugs. Immediate truncation on the user code sode is also riskless, just > > ugly. > > I'm not talking about porting code. > I'm talking about new code written in 2024. If we choose now to have 32-bit > count(), that will still be the case in 2024, possibly beyond, which means as > a result code written at that time needs to be careful not to use the 32-bit > methods. > > That's what I am referring to when I say a problem down the road. And I am concerned about porting code, because that's what keeps me busy nowadays. 2024 is four years ahead. That's quite some time in Qt's life. 2011's burning platforms looked different in 2015, and 2015's paradigms (OpenG?L, JS?) do not apply in 2019 anymore. It's ok to keep in mind that there will be 2024 at some time, but it's nothing worth sacrificing current usability for. Unless the rest of Qt interface is adapted to use qsizetype, including places where it's obvious overkill like, say, QComboBox::maxVisibleItems, user code will from 6.0 always have to decide on what integer type to use. This is trivial for each instance, but since _a lot_ of code is affected, this will sum up to a significant effort when writing and reading Qt code. Andre' ___ 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] RFC: QVariant changes in Qt6
Il 24/11/19 18:57, Olivier Goffart ha scritto: The issue is that there is lots of use of these (esp. the most common ones like toString and toInt.) Removing all uses be a huge work for no obvious reasons. (And i was told they are now recommended by clazy) The reason was avoiding the template bloat of the instantiations of value in client code, while such instantiations exist already in QtCore under a "different form" -- if T is int, QString, etc. then there's toInt(), toString() and so on. (I'm not sure of the overall impact, though.) If we can use extern templates for the same purpose, then we could drop the clazy warning for Qt 6, keep the toFoo() as porting aids and just make them inline calls to value(). My 2 c, -- 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
> 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] Notes from "Releasing" session in QtCon19
> -Original Message- > From: Development On Behalf Of > André Hartmann > Sent: Saturday, 23 November 2019 2:02 PM > To: Christian Ehrlicher ; development@qt- > project.org > Subject: Re: [Development] Notes from "Releasing" session in QtCon19 > > Hi all, > > > The script creating the changlog still oversees a lot of QTBUG - > entries. > > I > could not find out why the bug number is sometimes added > to> the changelog entry and sometimes doesn't.> See for example> > https://codereview.qt-project.org/c/qt/qtbase/+/281862/2..3/dist/changes- > 5.14.0 > > I've experienced the same with > https://codereview.qt- > project.org/c/qt/qtserialbus/+/281838/1..4/dist/changes-5.14.0 > > Had to add many of them by hand. There is a better tool for the job: https://lists.qt-project.org/pipermail/development/2019-April/035545.html > Greetings, > André > > > > > > Cheers, > > Christian > > ___ > > 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
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] RFC: QVariant changes in Qt6
> On 24. Nov 2019, at 18:57, Olivier Goffart wrote:
>
> On 24.11.19 12:36, Lars Knoll wrote:
>> Hi Olivier,
>> Thanks for looking through this and coming up with a proposal. I like the
>> direction.
>>> On 22 Nov 2019, at 14:32, Olivier Goffart wrote:
>>>
>>> Hi,
>>>
>>> This is a follow-up on what was discussed in the (second part of the)
>>> QtCore session in the QtCS.
>>> Lars and others have been mentioning that they dislike implicit conversions
>>> within QVariant. Creating a new class (QAny) has been suggested, that would
>>> be like QVariant but without the conversions.
>>> I am personally not in favor of this change because we are using QVariant
>>> all over the place in our API and so we cannot really deprecate QVariant.
>>> It will cause much confusion to user to have two similar classes. And the
>>> difference is not big enough to force a new class.
>>>
>>> So here is what I suggest we do in Qt6. None of this is implemented yet, it
>>> is only proposed on this list for feedback.
>>>
>>>
>>> 1. operator==
>>>
>>> In Qt6, QVariant::operator==() will no longer do any conversions.
>>> If two QVariant does not have exactly the same, they will no longer be
>>> considered equal.
>>> Also, in Qt6, QMetatype will gain ability to register the operator==, and
>>> therefore it will work for any type (and not only for builtin type as
>>> currently).
>>>
>>> So right now,
>>> QVariant(QByteArray("Hello")) == QVariant(QString("Hello"))
>>> is true, but in Qt6 it will be false.
>>>
>>> This is a behavior change, but I believe this is something we can afford to
>>> do.
>>> I do not have data on how much code will break with this change, but i feel
>>> most use of operator== are there for optimisations: i.e: setFoo(const
>>> QVariant ) { if (m_foo == foo) return; ... }
>>> Maybe we'll have more data once we actually implement the change and see if
>>> too many things breaks.
>> This should be relatively uncontroversial. The current behaviour is at the
>> very least unexpected by users.
>>>
>>>
>>> 2. operator< and other comparison operator
>>>
>>> Deprecate in Qt 5.15, remove in Qt 6
>>>
>>> It is not possible to implement it correctly with a total order.
>>>
>>> I could not find direct use of the operator in the code indexed on
>>> https://code.woboq.org/qt5 (only in QmlDesigner::operator< which is itself
>>> not used)
>>> Sorting on variant does not really make sense. Even code that does, like
>>> QAbstractItemModelPrivate::isVariantLessThan does not use operator<.
>>>
>>> Where this is used may be the use of QVariant as a key in a QMap. This is
>>> problematic because the operator< does not implement a total order, so you
>>> can have funny results.
>>> I could not find instances of that in Qt or QtCreator, but Github search
>>> for "QMap>> I'd still want to deprecate it. User could wrap QVariant in their own
>>> MySortedVariant with their own operators that does what they need for their
>>> use case.
>> +1. Total ordering will only work in special cases, as we do not control the
>> types of data stored in a QVariant. Using a QMap sounds like a
>> design mistake in any case. Let’s deprecate and remove in Qt 6.
>
> Deprecation MR: https://codereview.qt-project.org/282432
>
> Other things came up, QMetaType::registerComparators also register the
> operator<, but i suggest leaving it as it in 5.15 (as it is usefull to
> register operator==) and make it a deprecated no-op in Qt6
>
> There is also QMetaType::compare which has then to be removed in Qt6. I
> couldn't find any use of this function on github that was not some
> automaticaly generated bindings, or the tests within Qt itself. I guess it's
> Ok to deprecate it in Qt 5.15 as well even if there is no replacement. Or
> would it be ok to just remove it.
>
>>> 3. conversions in QVariant::value
>>>
>>> We would like to avoid having automatic conversion in QVariant::value.
>>> So Qt6 would be
>>> std::optional QVariant::value() const;
>>> And we could deprecate the current one in Qt5.15 in favor of qvariant_cast
>>> which is explicit.
>>>
>>> This one is a bit more controversial maybe. Because there are thousands of
>>> call to QVariant::value all over the place. But "value()" is the ideal name
>>> for the non-converting variant.
>>> A clazy script to replace QVariant::value with qvariant_cast will be in
>>> order.
>> I like this idea. value() is the perfect API to return the value of the
>> variant without implicit conversions. The advantage of the above approach is
>> that it offers a way to already migrate in Qt 5 and will give compile errors
>> in Qt6 for code that hasn’t been migrated to use qvariant_cast.
>> One more idea here: qvariant_cast was done as a free standing function
>> because of limitations in VC++ 6. We could also add a template
>> QVariant::cast() (or maybe to() or convertedTo()). IMO that would make
>> the code look a bit nicer than using the freestanding
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
[Development] QtCS2019: moc and QMetaObject
Here are the notes from the session https://wiki.qt.io/Qt_Contributors_Summit_2019_-_moc_and_QMetaObject Summary: We discuss if we should rewrite moc using libclang. moc currently hasn't still fully be ported to support C++11 yet. Features such as raw literals, trailing returns and other will confuse moc. It is agreed that using clang for moc would be the path forward even if it is slower. We discussed that we should use the clang C API for compatibility reasons. we should avoid using Qt in the implementation to simplify the bootstrap proccess. There is already a prototype i made years ago (but it is using the C++ API) https://github.com/woboq/moc-ng However this was not seen as a blocking issue for Qt6 as the changes we want to do to the "generator" can easily be ported to the new moc without requiring to do all the work twice.. We discussed if Qt should provide an additional API such as https://github.com/woboq/verdigris which allow to write code that does not use moc. But the consensus is that this wasn't usefull, and that verdigris can stay a separate library. However it should still be made possible. (And a solution for the new json output required by QML3 will be needed) We discussed the reflexion features coming in future version of C++. But since this is for the far future and won't help us immediately, we won't consider them now. Later they can be adopted. The QMetaObject itself will gain new feature for performance reasons so QML can be faster. -- Olivier ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
