Re: [Development] Drop MSVC 2015 in Qt 5.15?
On Sat, 23 May 2020 at 04:01, Thiago Macieira wrote: > > On Friday, 22 May 2020 02:21:29 PDT Tony Sarajärvi wrote: > > Hi > > > > Now open for discussion: https://bugreports.qt.io/browse/QTQAINFRA-3745 > > > > Based on Thiago’s comment that we don’t want to keep supporting it for > > years: > > https://codereview.qt-project.org/c/qt/qtdoc/+/269546 > > My opinion is clear. +1 Kill it with fire. +1 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QUtf8String{, View}
On Saturday, 23 May 2020 05:39:37 PDT Giuseppe D'Angelo via Development wrote: > To elaborate on this: does operator==(QStringView, char*) already exist > (maybe under QT_NO_CAST...)? If yes, isn't that char* already assumed to > be UTF-8? Do you want a QUtf8StringView to cleanly compile also under > QT_NO_CAST_FROM_ASCII (and obviously use UTF-8, not Latin1), to reap > compile-time strlen, etc? All of the above. -- 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] QUtf8String{, View}
Il 23/05/20 03:06, Thiago Macieira ha scritto:
As we're reviewing the changes Lars is making to get rid of QStringRef, Lars,
Marc and I came to the conclusion that QUtf8StringView is required for Qt 6.0.
That's because some methods that previously returned QStringRef now return
QStringView and to retain compatibility with:
if (xml.attribute("foo") == "bar")
where QXmlStreamReader::attribute() returns QStringView, we really need to
capture that "bar" as a UTF-8 string and we ought to have optimised UTF-16 to
UTF-8 comparisons. So we're working on it.
To elaborate on this: does operator==(QStringView, char*) already exist
(maybe under QT_NO_CAST...)? If yes, isn't that char* already assumed to
be UTF-8? Do you want a QUtf8StringView to cleanly compile also under
QT_NO_CAST_FROM_ASCII (and obviously use UTF-8, not Latin1), to reap
compile-time strlen, etc?
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] Qt Multimedia as Add-on in Qt 6
Den fre 22 maj 2020 kl 21:40 skrev Giuseppe D'Angelo via Development : > > On 5/22/20 7:43 PM, Jason H wrote: > > I guess to some degree it depends on how you define "essential". > > The definition is: > > "Qt Essentials define the foundation of Qt on all platforms. They are > available on all supported development platforms and on the tested > target platforms." Let me include more of that quote [1]: "[...] Essential modules are general and useful for a majority of Qt applications. A module that is used for a special purpose is considered an add-on module even if it is available on all supported platforms." I agree that according to that definition, QtMultimedia (and arguably QtSQL?) is not essential. Though it's going to be hard in some cases to determine if something is clearly useful for a majority of Qt applications.. I mean, what about QtNetwork? One could say that is "special purpose", but somehow I don't think it's going to be dropped from Essentials :) Elvis [1] https://doc.qt.io/qt-5/qtmodules.html#qt-essentials > > This summarizes two distinct requirements: > > 1) a technical requirement: the module must work on all platforms. > > 2) a maintenance requirement: the module maintainers must ensure it will > work on all platforms throughout Qt 6.x lifetime (and if it doesn't, on > ANY platform, it becomes a release blocker). > > > QtMM may satisfy 1) (at the moment, cf. making it work on RTOS or so) > but you can't argue with the maintainer about 2). > > > On the other hand: "addon" does not mean "deprecated" or "unsupported" > or any of the sorts. Qt3D, QtDbus, QtWebEngine, QtImageFormats and many > others are "addon" modules and they are fully supported. > > 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 > > ___ > 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] QUtf8String{, View}
Am 23.05.20 um 03:06 schrieb Thiago Macieira:
On Thursday, 14 May 2020 07:41:45 PDT Marc Mutz via Development wrote:
There's only our own lazyness which stands in the way of this better
alternative.
[snip the rest]
Update:
As we're reviewing the changes Lars is making to get rid of QStringRef, Lars,
Marc and I came to the conclusion that QUtf8StringView is required for Qt 6.0.
That's because some methods that previously returned QStringRef now return
QStringView and to retain compatibility with:
if (xml.attribute("foo") == "bar")
where QXmlStreamReader::attribute() returns QStringView, we really need to
capture that "bar" as a UTF-8 string and we ought to have optimised UTF-16 to
UTF-8 comparisons. So we're working on it.
If it had been wrapped in QLatin1String(), there would be no compatibility
issues, as there already is an operator==() for QStringView/QLatin1String.
There are currently no conclusions on QUtf8String and QAnyString, nor on what
the APIs should look like.
This also needs a solution in the other direction, QXmlStreamWriter:
This is painfully slow, despite UTF-8 XML, UTF-8 source code (element
names, attribute names) and data which might be used as - or transformed
to - UTF-8 directly. Everything needs to go to UTF-16 first (QString),
and then back to UTF-8. Allocations, Reference counting, no SSO...
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] MaintenanceTool and/or InstallerFramework horribly insecure?
Hi Kai, thanks for looking into this. One more discovery: the Qt Account credentials are also stored with 0557 permissions - they really should be 0600 for the file and 0700 or 0755 for the directory. Credential storage permissions should always be overridden anyway and not be left to some automatic mechanism, like umask. In case this is of interest: my umask is 0022. In an ideal world it would even ask permission to store credentials in the first place, even better it could use a system service for storing them securely (kwallet, Gnome Keyring, Windows credentials store, ...). Wishful thinking... On 2020-05-23 06:13, Kai Köhne wrote: > thanks for the report. Volker forwarded it to the qt-project security mailing > list. Feel free to send further security related issues there. Thanks & I put it on Cc now. >> When I call MaintenanceTool to install another version of Qt it wants to >> sudo into root when it starts to download Qt components. It still asks >> for the sudo password if I quit while selecting components! > I assume you start a new installer here (not the MaintenanceTool of an > existing installation). Is that really during the download, or in the > extractio phase? Can you maybe create a bug report and attach the > installation log (you can start the installer with --verbose)? No, that was an existing MaintenanceTool, which first updated itself and then restarted into normal updates. It switches into root as soon as you leave the package selection screen. Regardless of variant: it should never set insecure permissions, it should correct insecure permissions when it encounters them on crucial files/directories and it should not elevate its privileges unless absolutely necessary - and then it should ask. (According to RFC2119 this "should" should really be "must"... ;-) ) BTW: it still has the bug that the default selection is "remove All" - after discovering those bugs I granted that wish, killed it and installed from source. So sadly no traces of MaintenanceTool or its logs are left on this machine. As far as I could see at the time there were no usable hints about this directory or permissions in this log, I'm not sure about starting the root process. If I have excessive amounts of time next week, I might retry this on my work machine - but I really have strong feelings about exposing it to such security nightmares. >> Worse, if I normally have sudo set to NOPASSWD then it does not even ask, it >> just switches! > This is now tracked in https://bugreports.qt.io/browse/QTIFW-1794 Thanks! As I wrote in my first mail: I highly recommend TQtC invests in a security audit for this tool - it is a crucial component that potentially exposes a lot of paying customers. The presence of bugs like the above seems to suggest that there may be more bad practices hidden inside. E.g. is the network transfer really secure against MITM? From my own experience: to have an audit performed on your code can be a pain in the behind, but it is worth it - the code is significantly improved. Konrad signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Multimedia as Add-on in Qt 6
Any application in 'entertrainment' domain needs multimedia support. Most trivial case are games or (car) infotainment systems but almost any (android) app could have some sound notifications for raising user awareness/indicating some error, etc. So, when there is user-interaction there is usually some place for some media, too Br, Zoltan On Friday, May 22, 2020, Matthew Woehlke wrote: > On 22/05/2020 13.43, Jason H wrote: > > How about I just pay - which my company already does? The lagging > > mobile support has us considering moving away from Qt. I think this > > decision would confirm our direction and only hasten our departure > > from the Qt ecosystem. > > > > I guess to some degree it depends on how you define "essential". > > Clearly multimedia *is* essential > What's "clear" to you may not be "clear" to everyone. I, personally, > don't believe I have ever used QtMM. I can think of applications I might > *like* to write that might use it, but plenty of applications I *do* > write have no need for it. Most KDE applications don't need it. QtC and > Designer don't need it. > > In fact, out of the software I use in a typical day, the only stuff that > comes to mind that might need it are: > > - Gwenview (but it's more a nice-to-have) > - Plasma? (Whatever is responsible for system notifications, anyway) > - My web browser (except I use Firefox, which does not use Qt...) > - Dragon > > Really, the only three things I would argue *need* it are my web > browser, media player, and the desktop environment itself. > > For quite a few application developers, it is *not* essential at all. > > -- > Matthew > ___ > 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
