| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
When using a FBO, the source rect should be the painted part
(m_textureSize) of the FBO.
Also, the texture size is now correctly set when using an Image
render target.
Task-number: QTBUG-52054
Change-Id: If5d7a9c0b02f16f5d4be2cdf8c3c4cb15cb0583e
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|
|
|
|
|
| |
Change-Id: I3b61c1cdbad7a34170d8b1495611d525bbf6b220
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Add compiler option -d2SSAOptimizer- for this version of the compiler
since it causes crashes.
Task-number: QTBUG-55238
Change-Id: I9b38c669ad25f519150dd352b402dec982dc5555
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
Change-Id: I821ea14f60871735bface4e2cf4e61fcb61b2784
Task-number: QTBUG-55567
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When compiled in release mode with GCC 6, QtQml may crash.
This is because the C++ compiler is more aggressive about dead-store
elimination in situations where a memory store to a location precedes
the construction of an object at that memory location.
The QV4::MemoryManager::allocate{Managed,Object} functions allocate
memory and write to it before the caller does a placement new to
construct an object in the same memory. The compiler considers these
writes before the constructor as "dead stores" and eliminates them.
The -fno-lifetime-dse compiler flag is added to disable this more
aggressive dead-store eliminiation optimization.
This is a temporary workaround until a proper solution is found.
Task-number: QTBUG-55482
Change-Id: I7dbae6e9e613e53ce5fb25957c449bc6657803b5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
QDrag's constructor parameter is used as drag source in a DnD operation;
objects receiving QDrag{Enter,Move,Leave}Event will get this object when
calling event->source().
Task-number: QTBUG-54195
Change-Id: Id3ed7e8d62a8539983c7c21c45f8f1d72f9a2e30
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On shutdown the test will unload all the plugins it loaded. In the case
of the QtQuick2 plugin we only loaded it but never called registerTypes,
as the test merely sees if the plugin can be instantiated. Consequently
the attempt at unregistering the value type providers will fail because
it was previously never defined.
Note: We can't just let the QQmlValueTypeProvider destructor take care
of the deregistration, as we do not truly unload plugins anymore
(thankfully). However the plugin object will be destroyed and along with
it we should correctly de-register the things we registered earlier,
otherwise when initializing the plugin again, we'll register handers
multiple times.
Task-number: QTBUG-55524
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 23527754d60780ac4830f1acd6a54d3487a2c362)
Change-Id: I52c9e4c33649966c6291fafaa2efc4242ada6788
|
|
|
|
|
|
|
|
|
|
| |
After enabling separate debug info for Apple platforms, the toolchain
creates dSYM directory hierarchies that mirror the real hierarchy. The
contained .dylib files are not dylib files, they cannot be loaded. Try
to skip any paths that may point to such a hierarchy.
Change-Id: Iaee98a657495f31229c29ecd53a63e6493e70aff
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Doing it in QSG24BitTextMaskShader::initialize() assumed that the
FBO didn't change afterwards, but FBO can change (due to ShaderEffectSource
or item.grabToImage()), resulting in qt_sRGB_to_linear_RGB() getting called
for the case of the FBO not supporting sRGB.
The work done in 1e18a4f985f6ec is still a good idea (enabling sRGB for all FBOs),
and needed for exact rendering but this patch fixes an orthogonal issue.
Change-Id: I98b12347e9ef60f46d8bcb20ac5d0d2d7b0c6f57
Task-Id: QTBUG-52906
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Infinite-speed drags do not work well with velocity-sensitive
components like Flickable. As with change d04982dc on qtbase,
adding a short delay helps to stabilize tests.
To keep it flexible, we make QTest::defaultMouseDelay()
available via the qtest_events.defaultMouseDelay property.
So the delay can be increased by passing a larger delay
value to mouseDrag, or by changing the QTEST_MOUSEEVENT_DELAY
environment variable (as before).
Task-number: QTBUG-55382
Change-Id: I8f8088758a206be104a439ee0d1832eeca574e8c
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: I9b69dbe929947795bdfbff4e0e3a16a47fa94197
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
| |
Because it can lead to a use-after-free.
Change-Id: I6701b370c0ecee4967e5f749f673a6f9ee3d504c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
| |
These methods have real arguments.
Change-Id: I5362a407b8417b62bb27bb313dccce8611b5e316
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
| |
These methods have real arguments.
Change-Id: Ieb4ea8396876f237adedf5df8ab5aeec1055229f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
These methods have real arguments.
Change-Id: I61f42076d36265b58dcc598394c6b3576b02dd60
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC warned:
qtdeclarative/src/imports/localstorage/plugin.cpp:152:126: error: self-comparison always evaluates to true [-Werror=tautological-compare]
Fix by comparing the types for equality instead of the addresses of
their static_vtbls.
Task-number: QTBUG-53373
Change-Id: Idd1598610ad6381c03c3a46abe56a332726bd6a0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When exiting a catch block with a return statement, we'll unwind the
exception handling manually and emit finally statements right before
jumping to the exit block. If we throw an exception in the final block,
we'll end up using the exception handler of the catch block that
contains the return statement, which means we'll end up popping the
exception scope one too many times, once through
ScopeAndFinally::CatchScope in unwindException() and then when executing
the exception handler block. The latter we should not be executing,
instead we should jump straight to the exit block. Therefore any
statements emitted as part of the manual exception unwinding (finally
block here) need to be part of a new basic block with no exception
handler.
This bug became visible in debug builds where the Scope destructor
compares the scope mark against the engine stack top to ensure correct
cleanup order (which was wrong). However that in turn was hidden in
debug builds again due to an accidental = instead of == in a Q_ASSERT.
With the Q_ASSERT fixed this use-case is covered by
ch12/12.14/S12.14_A13_T3
Change-Id: Id74a1b2bb3e063871b89cc05353b601dd60df08e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
| |
Added the target wrappers shell scripts generated by commit
282f15feaae4c525602d537ab65cb61987eb5f7f from qtbase to the list of ignored
files. Similarly the config.log is also not desirable for version tracking.
Change-Id: I5cf832ea706f2109d2935cc6a086ece0979cc588
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
As of version 10.12 (Sierra), the name of Apple's desktop operating
system will be macOS. Change all occurrences where the Mac platform
is discussed to use the macro \macos (defined in the documentation
configuration in qtbase).
Change-Id: Iea114ac73c01d74401bcd77373b41a825d2636c9
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... when all (or almost all) items are in the cache.
When all items are in cache, check lower bound is equal
to upper_bound.
In rare cases, especially when almost all items are in cache,
the inserting code was used (not only appending and prepending).
In this code there was not bound check before creation of item
and there was such situation:
1. Create item by inserting code (without bound check)
2. At the next call of refill() remove this item by life cycle
because this item does not meet the conditions. And go to step 1.
In other words at the first call we create some item, at the second
remove this item. And again.
So we had infinite construction/destruction loop. To break it we
should check position of new item before creation in inserting code
too (like we do in appending and prepending code).
Task-number: QTBUG-37815
Change-Id: I015cdeb67ca5fcd06c34b3145b49cbd3e38d4078
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, QTest::mouseEvent() disregards the wall time for the time
stamps for events, but synthesizes the timestamps instead.
The proper way is to specify the waiting time in the delay argument.
This will adjust both the timestamp and perform a qWait() before the
event handler is called.
Without this patch, the qWait(doubleClickInterval) was disregarded, which
lead to that a doubleclick event was generated, and it failed with the
following message:
Actual (((window->rootObject()->property("doubleClicks").toInt()))): 2
Expected (1) : 1
tst_qquickmousearea.cpp(1105) : failure location
Change-Id: Ieda3b670d3cda0bd522db2f9677dad5745c88a21
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First call of QQuickPathView::refill() did not use currentIndex
for item prepending and there was situation when items were
not created, e.g.:
PathView with current item in center and currentIndex was set
so that item with index 0 was after current item and before path
end. The result of this situation: items from path begin to current
item were not created.
The reason was that idx always equaled (modelCount-1) for item
prepending.
Now first filling uses currentIndex to calculate valid idx.
Task-number: QTBUG-53464
Change-Id: I7e343b0712c9c5c5cd56b1d8e020cf8c0f6e6301
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
| |
This way it's accessible to the QML compiler.
Change-Id: I3918a796c698fc75e134b29a61eed2ec028bc851
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
| |
Coverity (CIDs 161677, 161674) caught us setting a bad example in our
example code.
Change-Id: I395f689586f9a6ad783328b9258096cbc9ccd692
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
|
|
|
|
|
|
|
|
| |
Greater uniformity; also opens the door to potential const-ing, should
this ever be worht considering.
Change-Id: I91b44472cb7d84f85b3033f14a763beeea837459
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
| |
Coverity (CID 163180) noticed _bindingTarget wasn't initialized.
Change-Id: Ia727d00a161e514c437a72084b6ef01a7ebf4abc
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial revert of 90b06e2773842, as it had unwanted side
effects. The original intention was to make assignment from char to
string possible, or more specifically, we wanted a solution where a
QChar could be assigned to a QString, as a character and not a string
representation of its value. While this behavior is desirable for
QChar, we most likely want the opposite for the regular character types.
Task-number: QTBUG-49232
Change-Id: I82d5f72b900fe984c4db1478fd52a9eb69ad2ee6
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Text elements may contain rich text with embedded links, and
need to accept left clicks to open them. However, setting the
textFormat to PlainText can disable mouse handling entirely,
as it is not required.
Accepting left clicks if there can be nothing to interact with
is unexpected and surprising, and can cause bugs in code that
performs child event filtering and doesn't expect Text elements
to produce child events.
Change-Id: Ibd5b9cf8d06fd30ea26f78b5393cc43e94646e73
Reviewed-by: Marco Martin <mart@kde.org>
Reviewed-by: Kai Uwe Broulik <kde@privat.broulik.de>
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, reading the documentation for modification of the global
object in JavaScript can be confusing.
http://doc.qt.io/qt-5/qtqml-javascript-hostenvironment.html says:
JavaScript code cannot modify the global object.
In QML, the global object is constant - existing properties cannot
be modified or deleted, and no new properties may be created.
...
Any attempt to modify the global object - either implicitly or
explicitly - will cause an exception. If uncaught, this will result
in a warning being printed, that includes the file and line number
of the offending code.
http://doc.qt.io/qt-5/qjsengine.html#globalObject says:
Returns this engine's Global Object.
By default, the Global Object contains the built-in objects that
are part of ECMA-262, such as Math, Date and String. Additionally,
you can set properties of the Global Object to make your own
extensions available to all script code. Non-local variables in
script code will be created as properties of the Global Object, as
well as local variables in global code.
If QQmlEngine "is-a" QJSEngine, and QJSEngine can have its global object
modified, it might seem reasonable to expect that imported JavaScript
code should be able to modify the global object.
This patch aims to be more explicit about the restrictions and give
examples of how libraries should expose their APIs correctly for use by
QML code.
Change-Id: I11beb894a88d52038be90ffe6baa9337943810db
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A call to a handler of Component.onDestruction may end up causing WeakValues
such as QQmlData::jsWrapper to be set again, even though they've been set to
undefined in an earlier iteration of the loop that walks through the weak
references. That in turn may result in invalid object references to objects
that are scheduled for destruction by the collector.
So after calling all destroy handlers for QObjects, reset all of the weak
values again.
Task-number: QTBUG-54939
Change-Id: I00ebabb76274e296fb1bd90d8d3e21dbbb920b57
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The distancefield cache did not clear the textures before using
them. Hence, random values could leak through in the edges of the
distancefields, leading to random pixels at the edges of the rendered
glyphs.
This issue was rarely visible before, because of the way the glyphs
were stacked on the textures. That stacking was changed as a result of
7190aa26f65ab97b4f54c156a107ed7748a11df5, which made the issue happen
more often, so it was detected by lancelot.
Change-Id: Ibe7a20dd7ba557ab92966e714c25a100e218ed24
Reviewed-by: Yoann Lopes <yoann.lopes@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason if a cache property is not found
this cause an application crash instead of just reporting an error.
Now instead of a crash we get this kind of error visible:
qrc:///the_file.qml line 64 column 30: Cannot assign object to property
Change-Id: Ic420713df30603f1d164da439cba30a18af8f2bc
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
This means we now respect -callgrind to show instruction counts (for instance).
If benchmarks don't already throw out outliers and perform averaging, we should
roll those features into testlib, not replace it.
Change-Id: I21a3c4b41ec80a49b5b61bfe957f1165ac865010
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
I have no idea what this was theoretically supposed to be testing, but it looks
completely bogus (not representative of a real world scenario), is subject to
massive variance thanks to memory allocation, and generally doesn't seem useful
Change-Id: Ib7adc8a4753e49d2a3bd9515273bca79a88a5749
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
There is no real sense in testing what boils down to operator new/delete plus a
little PLT overhead. For one thing, the allocator is too variant to test at such
a level. For another, it's not representative of any real-world scenario.
Change-Id: Ib455bb00839ff4e25099977059759a7b328db306
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
This is literally just testing operator new and delete, with a little PLT
overhead. It is not useful as a result (not a real-world scenario, and obscenely
variant thanks to allocators not being predictable in behavior).
Change-Id: I42f758c503b37ff880fc4f0e38c220d0638356e9
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
| |
Absolutely no need for this.
Change-Id: I06ca2dab157fecf2c585b9f863d9893cd4ce7300
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
It sometimes happens on touchscreens that mouse events occur too close
together. We cannot calculate velocity based on zero elapsed time,
so just ignore the event.
Task-number: QTBUG-45527
Change-Id: I120e73cfa60e2fcc594cb1f3b69f530e746abddd
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
There are segments top + border and for each segment 2 points -> 4.
Change-Id: I6df11e557054e4b942de430bd2cad8e2f798b0db
Task-number: QTBUG-51894
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It does not make a difference in functionality, but after engineAdded()
the server won't wait on a mutex anymore. Before this change, if you
managed to send a message to the V4 debugger after the server had
called aboutToBeAdded(), but before it had stopped waiting, you could
produce a deadlock by scheduling an event for the GUI thread that was
never delivered.
This is a cherry-pick of 18c4295e25503ae637a715858de5c94a3d105a92
from 5.7 as apparently the problem also occurs in 5.6.
Change-Id: Ie2343e6da4bd0b8956d41ff8ebd4d7594616ebd1
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
This is a test for commit 49c892328223dfa2502b462d8e5e8e181f4f6cd5
in qtbase
Change-Id: Id7be42ddd9136b73af08093117316fe2e86a000a
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
|
|
|
|
|
|
|
|
| |
With aggressive GC enabled we may end up calling the GC recursively, which does
not work at all, so disable that.
Change-Id: I9ce0abbdb7b2bfa8499b33fd0be0d6e4a5212a15
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
|
|
|
|
|
| |
Change-Id: Ifc047a7492d0452c86777f1e6a5671421b7065d3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
| |
Change-Id: Ib7bc3f62fc27e982f59f1c8b2c2e0cf26306c3b9
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
|
|
|
|
|
|
| |
EcmaScript doesn't in fact require the date to be represented in
english. Thus, only test for the year number to be contained in the
date string.
Change-Id: I5b89c14a833b317f259f4cd2855b3f24310a7d72
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
Calling QUrl::fromLocalFile() on a relative path leads to a non-relative
URL, as per the definition of QUrl::isRelative().
Change-Id: Ibaa9ecac56c6a14f6e41c5cf5250d7bbafed9837
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
These tests now can find their data files even when running from
a different directory than the source directory, and they no longer
misuse QUrl::fromLocalFile for a relative URL (resolved with
QUrl::resolved).
Change-Id: If18afd2e29571cca2a4c820eda6b9f6713e08a92
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 1e18a4f985f6ec4a0191a2e0cc087b13d29b1719.
It breaks a QtCanvas3D unit-test and I can't look at it now.
Will have another take at this soon.
Change-Id: I22acd55443783934596d25cc4c8774bd34609f6b
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
|
|
|
|
|
| |
Change-Id: I31781f32c2f9699f386a326f18cb5cc705582a89
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The extern declaration needs Q_CORE_EXPORT (which resolves to an import
declaration on MSVC). Also, the type of the qt_qhash_seed variable is
a QBasicAtomicInt, not int, so with proper signature mangling it would
not resolve (since memory layout is the same for an int and
a QBasicAtomicInt, it would just work for linkers that did not
detect it.)
Change-Id: I92375afcfc13e045e78a4d6cfdd539bd01b66136
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
|