Re: [Development] Feature freeze exception for QTBUG-95587
On 13/09/21 21:58, Elvis Stansvik wrote: > I don't see what's inherently wrong with a plain function like > Qt.resolvedUrl. It's very obvious - it says what it does on the tin. > Names are good that way. FWIW I've been using it for ages, and yes, if it initially it sounded a bit verbose, now I'm perfectly accustomed to it. > @ on the other hand would be completely opaque to a newcomer. > > When in a later mail, you reject qsUrl as an alternative to > Qt.resolvedUrl because 'it doesn't express "resolved"', I must ask: > How exactly does @ express "resolved"? qsUrl could be a nice addition, but even than, I don't feel such a strong need for it either. I think that the point raised by Oswald, about the waste of using "@" for such a narrow functionality, also deserves more attention. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6.2 QQmlMetaType incompatibility
Hi, instead of using QQmlMetaType::registerCustomStringConverter() you can add a static create() function that takes a QJSValue as argument to your class or have a ctor that takes QJSValue. Then register the type using QML_ANONYMOUS and it should be possible to create it from any JavaScript value assigned to it. You can also do a number of interesting and nasty things to wrap the existing QMarginsF into a value type. Take a look at qquickvaluetypes_p.h in qtdeclarative for "inspiration". The only thing shown there that you cannot do to your own value types is giving them names. The names passed to QML_VALUE_TYPE() are only decoration so far because the actual name resolution for value types is still hardcoded. best regards, Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Monthly CI maintenance break - October (Mon 4th Oct 2021)
Hi all! We’ll have our scheduled maintenance break on next Monday (4th of October). We’ll begin our work at 5:00 UTC and you can prepare for 6 hours of CI not working. This maintenance break is dependent on Qt 6.2 release coming out during this week. If that release is delayed, then this break is also delayed. Br, VP ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
