| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Change-Id: I05f140a0626e543535cc74c6f737be9be1e27a5d
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
|
| |
|
|
|
|
|
|
|
| |
Always use "if defined" instead of "ifdef". The same is valid for
"ifndef" macros
Change-Id: I8e8f65e36dc636c10b3d656ce9a89ab3a664a80b
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implementation of QQnxCursor, a QPlatformCursor subclass. Due to the lack of a
proper cursor API from the underlying OS, this class only caches the current
cursor position to make sure that the QCursor class works properly.
This is a backport of 290ed7f8fafd67197f773454223410bbe57fc4d3.
At the time there weren't any known bugs regarding this, so it was committed
to "dev" branch as a feature.
Now we needed it in "stable", otherwise menus don't work correctly, due to
QCursor::pos() being bogus.
Change-Id: I5a4217c92a0aaed0b22b45ca3c4e0fad882e810f
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The QPA plugin assumes in several places that we have at least
one QScreen.
Even if patching the plugin to support 0 screens, Qt itself crashes
when dereferencing a null paint device while synching the backing
store.
Change-Id: I2ac504a447aff811d6c07ab857340a3433557cdc
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
|
| |
|
|
|
|
|
|
|
| |
In blackberry, activation events come through the navigator,
but we might not have a navigator.
Change-Id: I0d9e1a08336aa403035fdf00be46d839a83f4b58
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
|
| |
|
|
|
|
|
| |
Qt coding style uses always 0. NULL is wrong.
Change-Id: I163677b512214f853677d21d75f13142fe2ca88d
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
|
| |
|
|
|
|
|
|
| |
Watch for display events from libscreen, and dynamically add and remove QPlatformScreens (and hence QScreens) in response.
Change-Id: I56dc7019a4d4c77798a0a88451d2f3060066f5d2
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
|
| |
|
|
|
|
|
|
| |
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
|
| |
|
|
|
|
|
|
|
| |
This behavior is now implemented in a finer way in QtQuick and
QtWidgets, it's not needed anymore in the platform plugin.
Change-Id: Iacdcd313253627fbba094abe4e9a9c1d23a431e1
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the recent refactoring in qtdeclarative for the handling of touch
and mouse events, QQuickCanvas automatically transforms touch events in
mouse events too.
It means that since we do something similar in the platform plugin, in
the case of QQuickCanvas the mouse event is duplicated. It it fine
except that having mouse event, touch event, mouse event in that order
is likely to mess the states of some elements. It happens to be the case
for MouseArea which will discard the second mouse event in the case of a
press, and because of that not receive the other events.
By changing the order in the plugin, we ensure getting events in the
following order: touch event, mouse event, mouse event. In the case of
MouseArea, since the press event will be accepted with nothing in
between, we'll keep receiving the other events.
Note that we can't simply remove the mouse event simulation on our side,
otherwise we'd break QWidget support.
Change-Id: If08fe0d97c6d60d0f858b228a014d94bc86dcf6f
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
|
| |
|
|
|
|
| |
Change-Id: I097e4af86a6a0941f4fd7e122970f88ba536ab38
Reviewed-by: Nicolas Arnaud-Cormos <nicolas@kdab.com>
Reviewed-by: Andriy Golovnya <andriy.golovnya@googlemail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We're not the only one creating native windows. When using the
multimedia API, the multimedia library creates a video window
for video display. Here we need to deal with giving this video
window overlay a proper z-order, otherwise it will never get
visible.
Change-Id: Ibff0382ebee5cda87408b91c8181a4104fc4a1a3
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Using QWindowSystemInterface::handleExtendedKeyEvent() instead of
QWindowSystemInterface::handleKeyEvent(). While the former allows
us to forward the native key codes to QWindowSystemInterface, the
latter initializes them with 0, causing QKeyEvent::native*() to
return 0, instead of the actual values.
Change-Id: I596ad2e07645e091529ca514682c98d095244a73
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
|
|
The event handler class can then be reused when we have proper
BPS event support available from corelib
Change-Id: Iafe645e69248597377045c711108ce0acbe3984b
Reviewed-by: Sean Harmer <sh@theharmers.co.uk>
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
