| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a window is resized AppKit groups all updates to the view frames and
corresponding layer bounds, so that the result of the resize is visually
atomic, but this only works for the main thread.
http://openradar.appspot.com/radar?id=4990815088672768
When a separate thread renders to one of the views in the window, it may
result in the view and its layer updating its bounds visually before the
resize has been visually reflected for the window itself and its border.
To ensure visually atomic updates, we disable all screen updates for the
process during resizing. This is the same workaround used by e.g. the
NSOpenPanel class, which renders the content of the view out of process,
and by Chromium for a similar use-case:
https://chromium-review.googlesource.com/c/chromium/src/+/798774
Ideally we'd do this only for the window that is being resized, but there's
no known API to do that. The deprecated [NSWindow disableScreenUpdatesUntilFlush]
is a no-op these days, and used NSDisableScreenUpdates internally anyways).
Fixes: QTBUG-69321
Change-Id: I84de714782278f2e0b2b2e1eb245c30810cb3023
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Set Qt::AA_DisableShaderDiskCache when the feature "disable_program_cache"
(modeled after the Chromium driver bug list) is present and set it for the
Intel HD Graphics 620 card.
Task-number: QTBUG-64697
Change-Id: Ibba588d2ab296b5c959ab8ee9712b47ec7cc906e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|\ \
| | |
| | |
| | | |
refs/staging/5.12
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
mkspecs/common/macx.conf
Change-Id: I8576493b417912fa5e5501bc2c1b935d186ac209
|
| | |\
| | | |
| | | |
| | | | |
Change-Id: I2fa26fa061cbf5d2bded203a299a19b7d1c31d0a
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This does not really work: as soon as you build with
the 10.14 SDK you opt-in to having updated palette
management, which the Qt 5.11 series does not have.
This leaves app developers with two ways to opt-out
of dark mode:
- Build with the 10.13 (or earlier) SDK.
- Set NSRequiresAquaSystemAppearance in Info.plist
This reverts commit 04671a80db32bd7fce470c50934cf60f2e8ffa70.
Change-Id: I5c01b9965da45de914f699526ba0723837f36e1d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Calling setView or update on NSOpenGLContext results in recreating the
internal GL surfaces of the view. Unfortunately there seems to be a
fixed amount of these surfaces available, so if we spin a loop where
we for some reason end up recreating them, we'll easily run out, and
lock up the whole window system:
thread #6, name = 'SwapThread'
frame #0: 0x00007fff7b45220a libsystem_kernel.dylib`mach_msg_trap + 10
frame #1: 0x00007fff7b451724 libsystem_kernel.dylib`mach_msg + 60
frame #2: 0x00007fff751c1675 SkyLight`SLSBindSurface + 247
frame #3: 0x00007fff5d9c4328 OpenGL`___lldb_unnamed_symbol29$$OpenGL + 255
frame #4: 0x00007fff6bf42c33 libGPUSupportMercury.dylib`gldAttachDrawable + 364
frame #5: 0x00007fff5d9e61e7 GLEngine`gliAttachDrawableWithOptions + 257
frame #6: 0x00007fff5d9c4bb0 OpenGL`___lldb_unnamed_symbol38$$OpenGL + 969
frame #7: 0x00007fff5d9c8b0e OpenGL`___lldb_unnamed_symbol57$$OpenGL + 82
frame #8: 0x00007fff5d9c8e55 OpenGL`CGLSetSurface + 330
frame #9: 0x00007fff50d0eb2c AppKit`NSOpenGLContextAttachOffScreenViewSurface + 352
This can happen e.g. when resizing the application, where AppKit itself spins
a loop where we don't end up back in QCocoaEventDispatcher::processEvents()
for each pass (where we do have a local pool). Or it can happen in the
render-loop of a render-thread that doesn't use the event dispatcher.
Change-Id: Iaf2f879dd01e3d807d0f35705ccc978dbc89036b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We don't need a separate QWindow pointer to keep track of the active
window, it's recorded already by the NSOpenGLContext's drawable.
And we don't need to juggle the drawable when the window is hidden,
the drawable is still valid after the window is re-shown, and we
call update on every frame (for now) anyways, which will reconfigure
the drawable if needed.
Change-Id: I199b6c027226dd239c13ecc4aba86986ca09a1eb
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Change 582d221b29 caused a regression when drawing menu items in
e.g a QComboBox. After that change, QCocoaSystemSettings would set the
QPalette::Highlight color to [NSColor selectedMenuItemTextColor]. But
the Highlight color is the background color, not the text color. And we
also use [NSColor selectedMenuItemTextColor] as the QPalette::HighlightedText
color. The result is that highlighed menu items end up with the same
foreground and background color (white), which means that they "disappear".
The color that we used before the patch, alternateSelectedControlColor, could
be used, but has the downside that it doesn't follow the appearance color in
system settings (like it should, compared to native apps). And it's also slightly
to blue. But using keyboardFocusIndicatorColor seems like a perfect match.
Fixes: QTBUG-69500
Change-Id: I07f091a5130a7308525743948d2a435226658a6f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Otherwise the user might accidentally render to the previously active
window, if not explicitly using an FBO.
This will have an performance impact if doing makeCurrent on a real
window and an offscreen window back and forth with the same context,
but that's not really a common or recommended use of QOffscreenSurface,
as you can create FBOs with a normal window current as well. The use
case of QOffscreenSurface is when a real window is not available.
Change-Id: If93d04f82564523e15d5970429afea34c5cd31fe
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
|\| |
| | |
| | |
| | | |
Change-Id: I66c7f18a2abd13601da0947919436f7da3549ae9
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It seems when a WebEngineView is parented by a window its accessible
interface will not know its parent, which prevented the root of an
UI Automation fragment from being found, causing missing accessibility
info. This change adds a workaround to avoid this issue.
Task-number: QTBUG-70199
Change-Id: Ia7cfc9f410c4f0ef3b5f9d1700748a9a3e29b7c2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
| |
| |
| |
| |
| | |
Change-Id: If92afa2d30d55e1dd2968f582350ba2cf16fe27b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Makes it easier to add shared logic later on.
The call to maybeCancelWaitForMoreEvents() has been left out as it was
not called from all call sites.
Change-Id: Ibcb10ab4d788de80850b0e5a4286b4d49091cddb
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I0be5125b434418c005f45f05c54b22f0418b46e4
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These fake mouse events should be synthesized by QtGui, not the QPA plugin,
when the tablet/touch events are not handled by the application and the
Qt::AA_SynthesizeMouseForUnhandledTouchEvents or
Qt::AA_SynthesizeMouseForUnhandledTabletEvents flags are set.
Task-number: QTBUG-47007
Task-number: QTBUG-60437
Change-Id: I4d6d5e6667d245c45a4eb4f3a94db05cf9772f52
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Romain Pokrzywka <romain.pokrzywka@gmail.com>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QOpenGlWidget and QuickQidget do not work at this time anyway.
This also causes gl to be initialized for widget apps, so disabling this
will optimize widget apps.
We could use Qt::AA_ForceRasterWidgets as well.
Task-number: QTBUG-67797
Change-Id: I8f86a9f72e6f3d437a818b4fbe3d6f3658e17d04
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The NSOpenGLPFAStereo attribute was deprecated in macOS 10.12, without
any replacement, and adding the attribute to the pixel format results
in context creation failure, so we're assuming the feature is no longer
supported an disable it wholesale on macOS.
Change-Id: I27d9f300fdaff9abe90781e3160b97f8b66121ad
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I3034258da95c9c70eb6758db92967f438617f6e9
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
We no longer support macOS 10.11, iOS/tvOS 10, or watchOS 3.
Change-Id: Ide03d8fac06185ef4162ba75ee54a0adf6916905
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the squashed diff from wip/webassembly to dev.
Done-with: Peng Wu <peng.wu@intopalo.com>
Done-with: Sami Enne <sami.enne@intopalo.com>
Done-with: Morten Johan Sørvig <morten.sorvig@qt.io>
Started-by: Andrew Knight <andrew.knight@intopalo.com>
Change-Id: I6562433c0a38d6ec49ab675e0f104f2665f3392d
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
translateTouchEvent needs to filter events based on the message type
passed in msg, as Windows sends more than just down/up/update events,
it also sends enter/leave for each touch and occasionally a few more.
One of them is WM_POINTERCAPTURECHANGED which indicates a general loss
of touch input, which needs to be translated to a touch cancel event.
Ignore WM_POINTERENTER/WM_POINTERLEAVE events as they result in sending
duplicate Qt::TouchPointPressed/Qt::TouchPointReleased events otherwise.
Also avoid sending duplicate events for each additional touchpoint:
Windows already bundles all available touchpoints for a touch event
when calling GetPointerFrameTouchInfo, so we get all points at once,
but we'll still receive other events for each additional touchpoint,
resulting in reading the same bundled data again for each one and
sending duplicate events to QWindowSystemInterface.
Use SkipPointerFrameMessages() to avoid receiving the additional
events for the frame we just processed.
Finally, add raw event logging when the platform verbose level is >1.
Change-Id: I55d840285f642a00f6ffcda4a3efd7ae3985310b
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Compute QPointF hi-res screen coordinates based on the HIMETRIC values
contained in the native message. This gives the same high-precision
screen coordinates as what the old WinTab handler supported.
Add the possibility to not synthesize mouse events if the platform
plugin option DontPassOsMouseEventsSynthesizedFromTouch is set,
just like we do for finger touches. This makes it possible to have
clean Pen events without mouse duplicates for an application that
handles both input types in parallel.
Add raw event logging when the platform verbose level is >1.
Change-Id: Ibf68b6275400388a76f8d5c573eed8f4b9bf4e9d
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
Replace local implementation of index_sequence with QtPrivate::IndexesList
Change-Id: I193b9183ec6832294687e979576a2e3ec56d550b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A multi-screen setup with an AMD adapter set as the 'main display' leads
to using the AMD drivers for OpenGL. This then causes a crash when calling
SetPixelFormat and similar for windows located on another adapter's
screen. This workaround detects the conditions leading to the crash and moves
the window to the main display.
Task-number: QTBUG-50371
Change-Id: I4007c490bdcdc13d6e8bce82983b150aa4930338
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/text/qtextengine.cpp
tests/auto/corelib/itemmodels/qsortfilterproxymodel_common/tst_qsortfilterproxymodel.cpp
tests/auto/corelib/itemmodels/qsortfilterproxymodel_common/tst_qsortfilterproxymodel.h
Change-Id: Ib9f968edbb0f3387c89bc25e914321d0738bfadc
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QAccessible::StaticText should be mapped to UIA_TextControlTypeId instead
of UIA_EditControlTypeId.
Task-number: QTBUG-69894
Change-Id: If2f8f55d2be492c02a3af5b1813ca12cf774a33a
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
According to MSDN, AltGr key presses are sent as a
sequence of SYS left Ctrl + right Alt.
Add an option to detect AltGr as modifier key.
Task-number: QTBUG-69317
Change-Id: I30ce169d2e6dbbae194ff714abfbc732b53652ce
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
|\ \
| | |
| | |
| | | |
Change-Id: I63f632b595f66d2fc93e9aa713500e3799e3df2a
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We detect if there's an upcoming momentum phase using the same trick
used by e.g. Mozilla in their event handling: https://tinyurl.com/yd8lcs4l,
and as recommended by an Apple engineer: https://tinyurl.com/y8yytlgv
The event is not guaranteed to be in the queue, but in practice it seems
to be. If this assumption fails we can add a wait timeout to the event
search instead of using [NSDate distantPast] as a timeout (which only
looks at queued events).
When the momentum phase is detected, QWheelEvent::phase will have the
new ScrollMomentum value, and the phase transitions will be
ScrollBegin -> ScrollUpdate -> ScrollMomentum -> ScrollEnd.
We no longer send ScrollEnd to signify that the user's fingers have
been lifted off the trackpad; rather, the first event with ScrollMomentum
phase means that the fingers have been lifted and macOS is now sending
simulated-momentum events.
This means ScrollEnd is a reliable indicator that the entire scroll
gesture (both the user interaction and the momentum) has ended.
If the ScrollMomentum phase is skipped, it means the user's fingers
came to rest before being lifted, so there is no momentum. In that case
the transitions will be ScrollBegin -> ScrollUpdate -> ScrollEnd.
Task-number: QTBUG-63026
Task-number: QTBUG-65160
Change-Id: I80191a472f6fa892387004c199166a6350124274
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
QAccessible::StaticText should be mapped to AutomationControlType_Text
instead of AutomationControlType_Edit.
Change-Id: If8c840f0dea553c1a750225586778a7d24cf424a
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Having these 2 lines in a function does not add much value and
requires scrolling that could be avoided.
Change-Id: Ife814be6478521cd64b0048d1b6ee447afea55de
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
QXcbConnection::internAtom() creates the atom if it does not exist. The
lifetime of an atom is not tied to the interning client. Atoms remain
defined until server reset (lost connection, restart).
So create the atom once via QXcbConnection::initializeAllAtoms(), and
later fetch the atom value from local array, instead of repeating
InternAtom requests.
Change-Id: I3cae21895febad6e5daf8c32e72612202baaad64
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add it to configure.json and replace all occurrences of QT_NO_THREAD
with QT_CONFIG(thread). Add conditions for other features that depend
on thread support. Remove conditions where we can use the QMutex and
QThreadStorage stubs.
Change-Id: I284e5d794fda9a4c6f4a1ab29e55aa686272a0eb
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
| |\ \
| | | |
| | | |
| | | | |
refs/staging/dev
|
| | |\|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/corelib/global/qconfig-bootstrapped.h
src/plugins/platforms/xcb/qxcbbackingstore.cpp
Done-with: Gatis Paeglis <gatis.paeglis@qt.io>
Change-Id: I4af138ffb2f5306373244523768209e8873b2798
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
qxcbimage.cpp:72:26: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
Task-number: QTBUG-69923
Change-Id: Icdb4ce8cb7ce5b48d7ee3839166eb1c7c9520c78
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Otherwise there is a -Werror=narrowing error on big-endian
architectures (where htons does nothing).
Task-number: QTBUG-68390
Change-Id: Idb204a81aaedb9f4fde1d5fae406da36c7a1953e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry-picked from b206d1c8082a9e01ad3755d311a4cf683ec35161)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This patch amends a62f1d03560937a306c7586669a46cd9575e9464.
If the initial backing store resize request is called with QSize(0, 0),
we end up with QXcbBackingStoreImage holding a default contructed QImage / m_qimage.
This happens because of the logic in QXcbBackingStoreImage::create(), where
if we detect that the requested segmentSize == 0, we do not allocate
any memory, and thus don't create a valid image in m_qimage. On subsequent
call to QXcbBackingStore::resize() we would only check if QXcbBackingStoreImage
object has been created, but not if it is in a valid state. This obviously
would cause problems.
This patch re-factors the logic to handle better resize to QSize(0, 0). And
make the code cleaner by:
- merging ::create and ::resize as semantically it is always resize().
- dropping unnecessary argument passing.
Task-number: QTBUG-69581
Change-Id: Ied337beb449dea8259fcf6b7d29f0a5bd553019d
Reviewed-by: Błażej Szczygieł <spaz16@wp.pl>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Until we can properly fix QPalette and QMacStyle,
we should disable dark appearance in Qt applications.
Disable by setting NSApp.appearance to Aqua, unless
dark mode support has been requested via Info.plist
or environment variable.
Read the NSRequiresAquaSystemAppearance Info.plist
key, don’t set NSApp.appearance if its value is false.
Also check the QT_MAC_REQUIRES_AQUA_SYSTEM_APPEARANCE
environment variable and apply similar logic. You then
enable dark mode support by setting:
QT_MAC_REQUIRES_AQUA_SYSTEM_APPEARANCE=0
which is slightly awkward, but matches Info.plist
behavior.
Task-number: QTBUG-68891
Change-Id: I86dc6cf3dee951d46c953396c57d2c31f2e4afcc
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- the usage of 'handled' variable was a mess.
- remove "generic" from API names. The naming was probably influenced
too much from underlying C API (xcb_generic_event_t):
- handleGenericEvent() -> handleNativeEvent() to be consistent with QWindow::nativeEvent().
- dropped unnecessary 'long *result' from signature. It is useful only on MS Windows.
- genericEventFilterType() -> nativeEventType(), it *is* an event type, not a filter type.
- XCB_CLIENT_MESSAGE was not passed to QWindow::nativeEvent(), which is done via
HANDLE_PLATFORM_WINDOW_EVENT.
- minor: added some 'auto's where it makes sense and improved some variable names.
Change-Id: Id1c9896054e2dbd9a79bacd88394149c8cf2cdea
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It was added 558dd7f58735716d7d1f61fb5323d807b178f0c7
It was missed after 128a6eec065dfe683e6d776183d63908ca02e8fb
Change-Id: I99f5c42ea45227bef08092e22d656e2d7d3cf60f
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's unclear what the original code was doing. It relied on 'm_release'
which could never be 'false' (ref. QTBUG-69679). It was subtracting event
times and comparing with arbitrary '10'. On X11 auto-repeat keys can be
detected by checking time and keycode of the current release event and
the next event in the queue. If an event is an auto-repeat, then next event
in the queue will be a key press with matching time and keycode.
Verified that auto-repeat was unreliable in Qt 4 as well. With this patch
auto-repeat works as expected.
Added support for Xlib's XPeekEvent in our XCB implementation QXcbConnection::checkEvent():
"The XPeekEvent() function returns the first event from the event queue,
but it does not remove the event from the queue."
Sneaking in one variable renaming: "string" -> "text", to match the QKeyEvent::text().
Task-number: QTBUG-57335
Task-number: QTBUG-69679
Change-Id: I0a23f138287f57eaaecf1a009bd939e7e0e23269
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: I7afe3bece5f143f6040cf1009d6345c1fe430367
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Few lines above we use the same attributes to create the window.
If attributes don't change, there is not need to call
xcb_change_window_attributes()
Change-Id: I1335b8be866bdd9911d7911c87f09091bf77e955
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
... clipboard_timeout is QXcbClipboard class member, accessible directly from
QXcbClipboard::waitForClipboardEvent().
Change-Id: Ibc241d1da4baedc0eaf84063251a1359b1cf4162
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
... to check for buffered events. This makes the code less verbose and
easier to read. Changed the filter signature to pass an event type in addition
to the actual event, for the convenience of API user. And do not pass worthless
nullptr-s to the filter.
The only reason why KeyChecker from qxcbkeyboard.cpp was not converted
to lambda expression is that the code looks suspicious - KeyChecker::m_release
default value is 'true' and I don't see where it would ever be assigned
'false' (ref. QTBUG-69679) and the code is known to be buggy (ref. QTBUG-57335).
Those issues are out-of-scope for this patch.
Change-Id: If2fdd60fbb93eb983f3c9ad616aaf04834fede9f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 823acb069d92b68b36f1b2bb59575bb0595275b4.
It caused some test failures in qtdeclarative and etc.
Task-number: QTBUG-69891
Change-Id: I2e4038a46de254834e6389c63f6dad0c2e523b8e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This caused a crash on destruction because as soon as you construct a
QTouchDevice it will register itself to a list of devices. On application
exit the function cleanupDevicesList() in qtouchdevice.cpp would go
through all registered QTouchDevices and destroy them. Therefore, there
is no need to delete the QTouchDevice from QWindowsPointerHandler.
This was a regression that was caused by
20d6dac63c25d227ed5315801e3e853ee78ec248
Change-Id: I58fb50016c047c3843a3f9677f2c2ef824223d43
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is not relevant anymore. C++11 is a hard requirement for a while already.
Change-Id: Idb8fbdcd13398cc85fba583f40c2b5c4dc7c4943
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|