Re: [Development] Maintenance break right now
Hi If I forgot to tell you that we have a maintenance break, so did I also forget to tell you that it is over. Aprox 8-9 hours ago I launched the CI and builds began passing again. -Tony From: Tony Sarajärvi Sent: tiistai 22. tammikuuta 2019 18.24 To: development@qt-project.org Subject: Maintenance break right now Sorry all, but we forgot to publicly announce that our firewall change is proceeding to the next phase right now. This means that for the next hours some of our web pages are going offline and the CI is brought down. I'll inform you when all is up and running again. -Tony ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Tuesday, 22 January 2019 09:01:16 PST Arnaud Clère wrote: > QByteArray is the official way to deal with utf8 strings but: > 1. This discussion shows it is not as known as it should be and I argue the > name does not help > 2. Dealing with binary data and all kind of string > encodings in a single class is error-prone And yet that's what we used to have in Qt 3 (remember QCString?). We went away from it for a reason. And 3: some character-mutating operations in QByteArray (toUpper, etc.) are Latin1, not UTF-8. > Hence my suggestion of adding a QUtf8String deriving from QByteArray... Not likely to happen. If we add a QUtf8String, it will be like QLatin1String, which in turn was meant to be similar to QStringView, not like QString. That means no mutation and no owning memory. And I don't want to add QUtf8String until SG16's char8_t gets settled. It'll probably be settled by C++20, which means we can probably work on this during Qt 6 lifetime, possibly even 6.1 or 6.2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Tuesday, 22 January 2019 11:02:22 PST Matthew Woehlke wrote: > On 18/01/2019 11.09, Thiago Macieira wrote: > > As for strings, the QString constructor takes UTF-8 input, but however > > fast > > the decoder is, it's still slightly slower than the Latin1 decoder. So if > > your string is purely US-ASCII, using QLatin1String is recommended. > > ...but I assume QStringLiteral remains even faster? (I would think so; > not only is *no* decoding needed, which you could also get just by using > wide string literals, but also no *allocation*...) Yes. In terms of CPU cycles, for a given string length of US-ASCII content: QUtf8::convertToUnicode > qt_from_latin1 > memcpy > ∅ (fromUtf8, fromLatin1, fromUtf16, QStringLiteral) The empty set symbol indicates that QStringLiteral is requires no operation on the content (O(1) on length). The others are O(n). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On 18/01/2019 11.09, Thiago Macieira wrote: > As for strings, the QString constructor takes UTF-8 input, but however fast > the decoder is, it's still slightly slower than the Latin1 decoder. So if > your > string is purely US-ASCII, using QLatin1String is recommended. ...but I assume QStringLiteral remains even faster? (I would think so; not only is *no* decoding needed, which you could also get just by using wide string literals, but also no *allocation*...) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
> Original Message- > From: Jason H > > > From: "Arnaud Clère" > > > > > -Original Message- > > > From: Allan Sandfeld Jensen > > > > > > Use QByteArray when you can. > > > > I think a QUtf8String class derived from QByteArray would help a lot making > > this happen in the real world! > > Feel free to burn this suggestion with fire, but what about: > > typedef QSymbolSequence QLatin1String; > typedef QSymbolSequence QByteArray; > typedef QSymbolSequence QByteArray; > typedef QSymbolSequence QString; > > So they can have the same API? It really seems to me that the issue is > storage, not that they need a different API to operate on the storage. This is close to QStringView and it would be nice to be able to build one from QByteArray/QUtf8String to access utf8 characters as QChar on the fly. It would avoid most MBCS problems with utf8 strings. Unfortunately, I am afraid this is not possible for QStringView since it must know the number of remaining characters and utf8 requires to decode the whole string to know that. My point was not as ambitious: QByteArray is the official way to deal with utf8 strings but: 1. This discussion shows it is not as known as it should be and I argue the name does not help 2. Dealing with binary data and all kind of string encodings in a single class is error-prone Hence my suggestion of adding a QUtf8String deriving from QByteArray... I have no idea if it would be feasible though ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Tuesday, 22 January 2019 06:49:51 PST Jason H wrote: > typedef QSymbolSequence QLatin1String; > typedef QSymbolSequence QByteArray; > typedef QSymbolSequence QByteArray; > typedef QSymbolSequence QString; > > So they can have the same API? It really seems to me that the issue is > storage, not that they need a different API to operate on the storage. That QSymbolSequence template class does not exist and is not easy to implement. Storage is not the problem, it's actually the algorithms that operate on and transform the contents. They'd have to be rewritten for each of the four. Go ahead and give it a try, though. This may also be what SG16 intends for C++23, so it may be an interesting trial run. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Maintenance break right now
Sorry all, but we forgot to publicly announce that our firewall change is proceeding to the next phase right now. This means that for the next hours some of our web pages are going offline and the CI is brought down. I'll inform you when all is up and running again. -Tony ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
> Sent: Monday, January 21, 2019 at 9:51 AM > From: "Arnaud Clère" > To: "Allan Sandfeld Jensen" , "development@qt-project.org" > > Subject: Re: [Development] Qt6: Adding UTF-8 storage support to QString > > > -Original Message- > > From: Allan Sandfeld Jensen > > > > On Dienstag, 15. Januar 2019 19:43:57 CET Cristian Adam wrote: > > > Any chance of having UTF-8 storage support for QString? > > > > > Use QByteArray when you can. > > I think a QUtf8String class derived from QByteArray would help a lot making > this happen in the real world! > 1. It would be found more easily by users in need of a utf8 encoded dynamic > string > 2. It would allow making the encoding explicit (QString or QUtf8String or > QLatin1String) in newer Qt APIs or user-defined ones, and even totally safe > if disabling const char * casts is possible > 3. It would allow adding QString-like APIs (like setNum(), simplified(), > etc.) over the time without cluttering QByteArray > > Moreover, I have a specific use-case where QByteArray args are used as binary > data (say CBOR) and a specific Utf8String is useful to handle utf8 encoded > args without always encoding/decoding to utf16. > I might not be the only one... Feel free to burn this suggestion with fire, but what about: typedef QSymbolSequence QLatin1String; typedef QSymbolSequence QByteArray; typedef QSymbolSequence QByteArray; typedef QSymbolSequence QString; So they can have the same API? It really seems to me that the issue is storage, not that they need a different API to operate on the storage. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Stepping down as the Qt Quick Controls 2 maintainer
Thanks JP! It's going to be hard to follow in your footsteps, but I'll do my best. :) Thanks to those who +1'd as well. On 1/22/19, 2:51 PM, "Frederik Gladhorn" wrote: Hi, It's been a while, so I'd like to congratulate Mitch on becoming maintainer for Controls 2 :) I'll update the wiki. Cheers, Frederik On mandag 26. november 2018 19:39:03 CET J-P Nurmi wrote: > Hi all, > > As you may have noticed, I haven't been actively working on Qt Quick > Controls 2 since last summer. I haven't had time to contribute, nor > fulfill my maintainer duties. I would therefore like to step down, and > propose Mitch Curtis as the new maintainer of the Qt Quick Controls 2 > module. Mitch participated in QQC2 development early on, and is a > natural choice as the new QQC2 maintainer. > > -- > J-P Nurmi > ___ > Development mailing list > developm...@lists.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] Stepping down as the Qt Quick Controls 2 maintainer
Hi, It's been a while, so I'd like to congratulate Mitch on becoming maintainer for Controls 2 :) I'll update the wiki. Cheers, Frederik On mandag 26. november 2018 19:39:03 CET J-P Nurmi wrote: > Hi all, > > As you may have noticed, I haven't been actively working on Qt Quick > Controls 2 since last summer. I haven't had time to contribute, nor > fulfill my maintainer duties. I would therefore like to step down, and > propose Mitch Curtis as the new maintainer of the Qt Quick Controls 2 > module. Mitch participated in QQC2 development early on, and is a > natural choice as the new QQC2 maintainer. > > -- > J-P Nurmi > ___ > Development mailing list > developm...@lists.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] Intention of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages
Hi, In order to improve transparency and visibility (after getting some constructive and well deserved criticism): We have received a proposal of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages. We looked at this today and agreed that this can be done, and it should be our intention to do so. We will make the final decision February 5th, and it will remain as described unless we get a lot of feedback saying that we should do otherwise. For further details: https://bugreports.qt.io/browse/QTBUG-73019 Regards, Harald Kjølberg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Merge and Integration status report - 2019.01.22
First issue on 2019! Generally, CI/COIN was in a very good mood after the new year update. Then we met https://bugreports.qt.io/browse/QTBUG-73116 , tst_QString::localeAwareCompare fails (dev) and a few other issues. Now it looks like most of them got fixed already. Merges * Submodules 5.12->dev merge are fine * qt5 5.12->dev merge is ongoing, see https://codereview.qt-project.org/#/c/249863/ , currently blocked by https://bugreports.qt.io/browse/QTQAINFRA-2591 , Windows 10 provisionigs stuck on sdkmanager, Tony is working on that, perhaps we need more Yes to those questions... Integrations * qt5 5.12.1/5.12 are healthy * qt5 dev is 5 days old, expected to have new round with qt5 5.12->dev merge after QTQAINFRA-2591 got fixed --Liang ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt for WebAssembly 5.13
Hi all, Qt for WebAssembly shipped as a tech preview for 5.12, and for 5,13 we want to fill in some of the missing pieces, and also make Q_OS_WASM a supported platform. Supported here does not mean that everything that does not work today will work, but rather that what we claim will work actually will work. And also that the Qt Company supports Qt on this platform, like Qt on the other platforms. The planned list of improvements includes: - Multithreading support (most likely opt-in) - System clipboard access - Local file access - Binary packages - Platform documentation This is mostly platform implementation work. We are looking to add new public API for the file access part, see https://codereview.qt-project.org/#/c/250462/ And finally a question for this list: What would you like to see be implemented for Qt for WebAssembly? Cheers, Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
