Re: [Development] Accelerating deprecation of MSVC 2017
On Tuesday, 20 August 2019 14:46:57 PDT Konstantin Tokarev wrote: > 21.08.2019, 00:45, "Thiago Macieira" : > > I'd like to propose we announce now that it will not be supported for Qt > > 5.15. > > > > Even if 2019 still has code generation problems. > > Does it mean that you recommend using 2015 instead? No, I recommend using 2019 because MS will fix it. 2015 is no longer supported in 5.13. Note I'm talking about 5.15, so it's only going to affect people mid 2020. MS has something like 9 months left to fix the code gen issues. -- 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] Accelerating deprecation of MSVC 2017
21.08.2019, 00:45, "Thiago Macieira" : > I'd like to propose we announce now that it will not be supported for Qt 5.15. > > Even if 2019 still has code generation problems. Does it mean that you recommend using 2015 instead? > We should assume that MS will > fix them soon. > > -- > 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 -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Accelerating deprecation of MSVC 2017
I'd like to propose we announce now that it will not be supported for Qt 5.15. Even if 2019 still has code generation problems. We should assume that MS will fix them soon. -- 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] HEADS-UP: QStringLiteral
On Tuesday, 20 August 2019 14:25:27 PDT Philippe wrote: > > There's no mutex. > > On Visual Studio 2017 15.8.8, That's a broken compiler, a regression from 2015 and fixed on 2019. Try *any* other compiler and you'll see there's no mutex. Same bug that makes static with VS 2017 crash on start. -- 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] HEADS-UP: QStringLiteral
> There's no mutex.
On Visual Studio 2017 15.8.8, there is a mutex on the 1st call
(checked today when step tracing the assembly code).
Again, for block scope, that is:
void foo()
{
QString s = QStringLiteral("abc");
...
}
Philippe
On Tue, 20 Aug 2019 14:11:59 -0700
Thiago Macieira wrote:
> On Tuesday, 20 August 2019 03:41:45 PDT Philippe wrote:
> > another Drawback : it causes a global mutex to be executed on first use
> > inside a block scope (c++11 static variable thread safety).
>
> There's no mutex.
>
> --
> 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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: QStringLiteral
On Tuesday, 20 August 2019 08:56:06 PDT Bogdan Vatra via Development wrote: > Isn't silly to have so many wrappers around a such a simple thing as > strings? We all wish it were simple. If it were, we would have no need for so many string classes, for Marc's email and even for SG16 (Unicode) to exist in the C++ committee. -- 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] HEADS-UP: QStringLiteral
On Tuesday, 20 August 2019 03:41:45 PDT Philippe wrote: > another Drawback : it causes a global mutex to be executed on first use > inside a block scope (c++11 static variable thread safety). There's no mutex. -- 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] HEADS-UP: QStringLiteral
On Tuesday, 20 August 2019 03:04:12 PDT Mutz, Marc via Development wrote: > - You can use u"..." in Qt sources unconditionally >- converts implicitly to QStringView And you can use UTF-8 text there[*], since all our compilers now support UTF-8 and are configured to parse it. [*] untested with ICC on Windows and with INTEGRITY's compiler. It's assumed that they do and if they don't, it's a compiler bug. -- 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] QObject enum not readable in QML with Qt 5.12.4
Fabrice Mousset (20 August 2019 18:05) > I've got this issue when qtquickcompiler is enabled! > When I remove qtquickcompiler, it works! Please file a bug report against the qtquickcompiler, Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QObject enum not readable in QML with Qt 5.12.4
Hi all,
I am **modernizing** our application from Qt 5.4.2 to last LTS version (Qt
5.12.4).
I have a problem which I can't understand and needs some help.
I have declared a QQuickPaintedItem object which has an enumeration to defined
drawing types, like this:
class TourPlayerItem : public QQuickPaintedItem
{
Q_OBJECT
public:
enum DrawType // used also for draw order!
{
DrawTypeNormal,
DrawTypeBackward,
DrawTypeWorkRegion,
DrawTypeContainerRegionSingle,
DrawTypeContainerRegionDouble,
DrawTypeOffline,
...
};
#if QT_VERSION < QT_VERSION_CHECK(5, 5, 0)
Q_ENUMS(DrawType)
#else
Q_ENUM(DrawType)
#endif
...
}
This class is registered to be accessible from QML:
qmlRegisterType("com.Geocept.Tour", 1, 0, "GCTourPlayer");
In QML, this class is used like this:
GCTourPlayer {
id: tourPlayerTrace
anchors.fill: parent
drawTypes: [
DrawType { type: GCTourPlayer. DrawTypeBackward; color:
'#D9004D9E' },
DrawType { type: GCTourPlayer.DrawTypeSubSections; color:
'#E67814A0' }
]
}
When I do this, I've got always '0' for type (color value is working well).
When I replace "GCTourPlayer.DrawTypeBackward " and
"GCTourPlayer.DrawTypeSubSections" with corresponding integer value, type is
set with excepted value.
This works without any problem with Qt 5.4.2.
Do I something wrong?
Thanks for any helps
Best regards
Fabrice
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: QStringLiteral
Hi,
Isn't silly to have so many wrappers around a such a simple thing as
strings? All the major frameworks out there (i.e. Java, C#) they have a single
String which does all the magic.
In Qt we have: QString, lost of QString::fromXXX, QLatin1String,
QStringLiteral, QStringView, QByteArray (which si a castrated version of
QString for some kind of utf-8 strings) and of course a few QByteArray::from.
You might think using QString{u"myString"} will save you from all these
madness and to save a few CPU ticks, well, you have tot think again,
QString{u"myString"} isn't working!
Is it that hard to have *A* single String for UTF-16 and *A* single one for
UTF-8? Ot at least A single String class and *A* single sting wrapper for each
UTF?
Cheers,
BogDan.
În ziua de marți, 20 august 2019, la 13:04:12 EEST, Mutz, Marc via Development
a scris:
> Hi,
>
> In light of a recent attempt to re-introduce QStringLiteral, relacing
> QLatin1String, I'd like to remind everyone that QStringLiteral has a lot
> of drawbacks and should not be used unless it saves a memory allocation.
>
> Drawbacks include:
>
> - doubled storage requirements (2 bytes/char) over a L1/US-ASCII string
> - unsharability with C strings (each QStringLiteral contains a new
> lambda, lambdas have unique types, static data in token-for-token
> identical lambdas is duplicated, merging these violates the standard)
> - introduction of QString dtor calls (cannot be optimized away)
>
> Anti-patterns include: Using QStringLiteral in
>
> - comparisons (includes relational operators, indexOf, contains)
> - composition (QStringBuilder, append, prepend, arg() (now partly
> available on QStringView and QLatin1String, too)
> - lookup and, I believe, even insertion, in JSON and soon CBOR classes
> - debug statements (we prefer debug code to be compact, not fast)
> - arguments to any other function overloaded QStringView or
> QLatin1String
>
> Alternatives to QStringLiteral:
>
> - u"..." (→ QStringView)
> - QLatin1String
>
> Please take note of the following recent developments:
>
> - arg(string, , string) ("multiArg") is available now on QL1S and
> QStringView
>- number formatting isn't, yet
> - You can use u"..." in Qt sources unconditionally
>- converts implicitly to QStringView
> - To convert QString → QStringView, prefer qToStringViewIgnoringNull()
> when you don't need to distinguish between the null and the empty state.
> It saves a branch.
>
> Please help spreading this knowledge in review and your own work.
>
> Thanks,
> Marc
>
> ___
> 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] Updating holdover API from Qt 1 times
On 17/08/2019 00.13, Sze Howe Koh wrote: > QLabel returns some CoW types by-pointer as a legacy from Qt 1 times [1]: > > QPixmap *QLabel::pixmap() const; > QPixture *QLabel::pixmap() const; Does this allow one to obtain the internal pixmap and modify it in-place without then calling setPixmap? If so, note that changing these to return by value represents a non-trivial change to the API. (Although, perhaps that's a change we *want*...) > 3) Pick one of the options above, but go one step further and use > std::optional (C++17) instead of returning null objects. Ugh... I'm with Kevin; I think this doesn't make sense and adds a level of indirection for no good reason that will only make the API's harder to use. Please choose based on what produces the best API in the end, not the least porting effort. Otherwise we are just trading one sub-optimal API for another. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt 6 and C++17, slicing and dicing a master plan for it
I and Kari Oikarinen created an epic, some user stories, and further some sub-tasks what needs to be done related to C++17 usage in Qt 6. The link to the epic, under from which you can navigate to the more detailed levels, is here: https://bugreports.qt.io/browse/QTBUG-77477 Feedback, comments, suggestions etc. are welcome. We will most probably need to add much more 'meat' to the library-facility parts. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Maintainers, your action needed: Qt 5.12.5 changes files
Hi, Initial ones here: https://codereview.qt-project.org/q/message:%2522Add+changes+file+for+Qt+5.12.5%2522 Maintainers, please do needed modifications & make sure changes will be approved during this week. br, Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: QStringLiteral
another Drawback : it causes a global mutex to be executed on first use
inside a block scope (c++11 static variable thread safety).
Philippe
On Tue, 20 Aug 2019 12:04:12 +0200
"Mutz, Marc via Development" wrote:
> Hi,
>
> In light of a recent attempt to re-introduce QStringLiteral, relacing
> QLatin1String, I'd like to remind everyone that QStringLiteral has a lot
> of drawbacks and should not be used unless it saves a memory allocation.
>
> Drawbacks include:
>
> - doubled storage requirements (2 bytes/char) over a L1/US-ASCII string
> - unsharability with C strings (each QStringLiteral contains a new
> lambda, lambdas have unique types, static data in token-for-token
> identical lambdas is duplicated, merging these violates the standard)
> - introduction of QString dtor calls (cannot be optimized away)
>
> Anti-patterns include: Using QStringLiteral in
>
> - comparisons (includes relational operators, indexOf, contains)
> - composition (QStringBuilder, append, prepend, arg() (now partly
> available on QStringView and QLatin1String, too)
> - lookup and, I believe, even insertion, in JSON and soon CBOR classes
> - debug statements (we prefer debug code to be compact, not fast)
> - arguments to any other function overloaded QStringView or
> QLatin1String
>
> Alternatives to QStringLiteral:
>
> - u"..." (? QStringView)
> - QLatin1String
>
> Please take note of the following recent developments:
>
> - arg(string, , string) ("multiArg") is available now on QL1S and
> QStringView
>- number formatting isn't, yet
> - You can use u"..." in Qt sources unconditionally
>- converts implicitly to QStringView
> - To convert QString ? QStringView, prefer qToStringViewIgnoringNull()
> when you don't need to distinguish between the null and the empty state.
> It saves a branch.
>
> Please help spreading this knowledge in review and your own work.
>
> Thanks,
> Marc
>
> ___
> 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] HEADS-UP: QStringLiteral
Hi,
In light of a recent attempt to re-introduce QStringLiteral, relacing
QLatin1String, I'd like to remind everyone that QStringLiteral has a lot
of drawbacks and should not be used unless it saves a memory allocation.
Drawbacks include:
- doubled storage requirements (2 bytes/char) over a L1/US-ASCII string
- unsharability with C strings (each QStringLiteral contains a new
lambda, lambdas have unique types, static data in token-for-token
identical lambdas is duplicated, merging these violates the standard)
- introduction of QString dtor calls (cannot be optimized away)
Anti-patterns include: Using QStringLiteral in
- comparisons (includes relational operators, indexOf, contains)
- composition (QStringBuilder, append, prepend, arg() (now partly
available on QStringView and QLatin1String, too)
- lookup and, I believe, even insertion, in JSON and soon CBOR classes
- debug statements (we prefer debug code to be compact, not fast)
- arguments to any other function overloaded QStringView or
QLatin1String
Alternatives to QStringLiteral:
- u"..." (→ QStringView)
- QLatin1String
Please take note of the following recent developments:
- arg(string, , string) ("multiArg") is available now on QL1S and
QStringView
- number formatting isn't, yet
- You can use u"..." in Qt sources unconditionally
- converts implicitly to QStringView
- To convert QString → QStringView, prefer qToStringViewIgnoringNull()
when you don't need to distinguish between the null and the empty state.
It saves a branch.
Please help spreading this knowledge in review and your own work.
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] NTLM Issue with Qt-5.12 LTS
On Mon, Aug 19, 2019 at 1:04 PM Volker Hilsheimer wrote: > > On 19 Aug 2019, at 11:41, coroberti . wrote: > > Hi, > Could be this issue be given a priority since it's a regression > and strikes deployments of Qt-5.12 LTS on Windows? > > https://bugreports.qt.io/browse/QTBUG-44096 > > > > Hey Robert (and others), > > could you help with verifying the proposed fix in > > https://codereview.qt-project.org/c/qt/qtbase/+/265900 > > FWIW, from the report it doesn’t seem to be regression within Qt 5; the > report is originally against Qt 5.4, at least. > > Cheers, > Volker > Hi Volker, It appeared, however, that my server side has been changed by admin, and I cannot reproduce the original issue. I've applied the patch and tried. The good news it that there was no any badness introduced. Sorry, but it seems that somebody else with an appropriate setup is required to make the positive verification. Sorry for the buzz. Kind regards, Robert ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Repo request for Qt Quick 3D module
Repository has been created as requested. - Paul From: Development on behalf of Andy Nichols Date: Wednesday, 14 August 2019 at 12:24 To: "development@qt-project.org" Subject: [Development] Repo request for Qt Quick 3D module Hello everyone, As The Qt Company announced today on our blog, we have been working on creating a unified graphics story for our 2D and 3D Qt Quick API's and tooling. Part of this story is introducing a new module and API for defining 3D content in Qt Quick. https://blog.qt.io/blog/2019/08/14/introducing-qt-quick-3d-high-level-3d-api-qt-quick/ repo name: qtquick3d name: Qt Quick 3D responsible person: me (Andy Nichols) The code is currently hosted here: https://git.qt.io/annichol/qtquick3d This code represents the effort to start the process of integrating 3D content into Qt Quick's rendering, bound by the limitations of binary compatibility in Qt Declarative. The current code works against the Qt 5.12 LTS, and is a approximation of what we are trying to achieve as a whole. For Qt 6 we are planning to further integrate with the existing Qt Quick Scenegraph infrastructure so that more APIs can be shared (for example QSGTexture, QSGGeometry), as well as making it easier to have QQuickItem based components rendered in spatial contexts. There is a valid concern that this is yet another 3D solution for Qt, being that we currently are offering both Qt3D and Qt 3D Studio as supported solutions. As stated in the blog post, this isn't a replacement of Qt3D, as Qt3D is a low level API for creating 3D runtimes. With regard to Qt 3D Studio, this project is an evolution of that offering. Qt 3D Studio has the issue that the runtime it ships with overlaps very much so with Qt Quicks offering, while still leaving a lot of gaps in functionality that Qt Quick already provides. Rather than continuing to try and fill those gaps and fragment our HMI story further, we would rather extend Qt Quick to support a high level 3D API that Qt 3D Studio tries to provide. So with Qt Quick 3D we functionally have a QML API for using the features of Qt 3D Studio, while simultaneously enabling us to unify our tooling story for Qt Design Studio. Our goal is to reduce the amount of things we are working on in parallel, and focus our efforts on extending the functionality of Qt Quick. This goes hand-in-hand with the modernization of Qt Quick with the QtRHI work. We would like to provide a tech-preview of this module along with 5.14.0 and continue to develop the project further out in the open. Regards, Andy Nichols ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
