| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By specification, date conversion functions for dates before the epoch
are not DST corrected. We converted QTime to a QDateTime where we set
the date part to Jan. 1, 1970, and then convert that to msecs since the
epoch UTC. For places on Earth where they had DST on that day (e.g.
Hobart in Australia), strange things happen: conversion from a QTime to
DateObject will use DST (because it's after the epoch in local time),
but conversions from DateObject to QTime won't use the DST because it's
before the epoch (in UTC).
Now as everyone knows, a 24-hour clock time has no meaning without a
date, only "elapsed time" has. But users still expect to be able to pass
QTime to QML/JS. So, we do the conversion on day 0 of month 0 of year 0,
and all of it in local time. This gives a stable conversion in both
directions, and the values in both C++ and QML/JS are the same for any
timezone (with or without DST) on this planet.
Task-number: QTBUG-54378
Change-Id: I892e16a93f015e92d311c6cae3ae7768b7373f6a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to the Qt.quit() function but also specifies the return
code that the event loop will return.
[ChangeLog][QtQml] Added exit(int retCode) method to the Qt global object.
An application can call Qt.exit to specify a return code of the engine.
Task-number: QTBUG-54360
Change-Id: Iaa319e6dc4d6b99dc3a5c01845e87b936fd2cab0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/qml/qml/v8/qqmlbuiltinfunctions_p.h
tests/auto/qml/qqmlqt/tst_qqmlqt.cpp
Change-Id: I9dd93732f4b19513576ca1dd89ae18c69de0203b
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Only iterate over the enumerations/enumerators in the staticQtMetaObject
when a get() is done, and the key/value is not yet in stored in the
underlying Object. The whole cost of the iteration is now moved to get()
and advanceIterator(). The latter will add all items in one swoop, but
iteration over QtObject isn't used much (if at all). The get() will add
all key/value pairs up until it finds the requested key. Checking a
number of applications shows that none of them use all (or the "last")
key, so it will actually save entries (which equals memory) too.
This change reduces the instruction count for QtObject from 2.7M
instructions down to 95k. As this initialization is done from the
QQmlEngine constructor, it also speeds up that initialization.
Task-number: QTBUG-43770
Change-Id: I71331ff76bdacdd4790f7ff0430c4cbc214fe0ab
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Calling the new Qt.callLater() multiple times in quick succession with the same
JS function as argument will result in a single call to that function, thus
eliminating redundant unnecessary calls.
Based on previous patches by Mathias Malmqvist <mathias.malmqvist@nokia.com>
and Chris Adams <chris.adams@jollamobile.com>
Change-Id: Ie71b60d4d48fa73d3deae723775cf36662d199ae
Task-number: QTBUG-22400
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is more convenient than the alternative hsla() function in many
cases as color pickers in other applications default to the HSV color
space e.g. GIMP, kcolorchooser.
[ChangeLog][QtQml] Added Qt.hsva() function
Change-Id: Id5c1a78173757bf9842b164d90b31682e9a41749
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
|
|
|
|
|
| |
Change-Id: Ice5d60b06ec9ab81fbd98fd1679c8834f3018938
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
|
|
|
|
|
|
|
|
|
| |
Add the Qt.colorEqual() function which compares any combination of
two supplied color and string arguments, by converting the string
arguments to colors as necessary.
Task-number: QTBUG-18754
Change-Id: I75baef9a2edd30a5f8b9cb5e151e4adba6f6a371
Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In QtQuick 1.x the "variant" property type was supported, which could
be used to allow value type properties to be defined in QML. In
QtQuick 2.0, we have deprecated the "variant" property, but its
replacement ("var") is not suited for defining lightweight C++ type
values (such as QColor, QFont, QRectF, QVector3D etc).
This commit allows those QML basic types to be used in QML once more,
by supporting them in the property definition syntax.
Note that since some value types are provided by QtQuick and others
are provided by QtQml, if a client imports only QtQml they can define
but not use properties of certain types (eg, font).
Task-number: QTBUG-21034
Task-number: QTBUG-18217
Change-Id: Ia951a8522f223408d27293bb96c276281a710277
Reviewed-by: Matthew Vogt <matthew.vogt@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not use the 3rd-party code from JSC, but instead use the QDateTime
functions for millisecond offsets from the epoch.
Note that this change is reviving the earlier change:
http://codereview.qt-project.org/1874. The test failures for that
change no longer occur due to a change in the QDateTime behavior
applied by: http://codereview.qt-project.org/13169
There is still a semantic difference between QDateTime and the
ECMAScript specification with regards to the application of DST.
ECMAScript requires that the current DST adjustment should be applied
to historical dates, whereas QDateTime will apply the adjustment as
applicable at the epoch date to any prior dates.
Change-Id: Ibebd47c9d2b75a034342ffcda075501a6a527b8d
Reviewed-by: Chris Adams <christopher.adams@nokia.com>
|
|
|
|
|
|
|
| |
Enables threaded compilation for a Loader "source".
Change-Id: I2d60a3ace07aab58f3b8f069e45a2864178c959f
Reviewed-by: Chris Adams <christopher.adams@nokia.com>
|
|
Symbols beginning with QDeclarative are already exported
by the quick1 module.
Users can apply the bin/rename-qtdeclarative-symbols.sh
script to modify client code using the previous names of the
renamed symbols.
Task-number: QTBUG-23737
Change-Id: Ifaa482663767634931e8711a8e9bf6e404859e66
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|