| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/network/access/qnetworkreply.cpp
tests/auto/corelib/kernel/qmetaobject/tst_qmetaobject.cpp
Change-Id: Iadf766269454087e69fb216fc3857d85b0ddfaad
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
.. when running event loop with QEventLoop::ExcludeUserInputEvents.
In a properly functioning code, g_main_context_iteration is expected
to block until any event source becomes ready to dispatch an event
(or interrupt occurs). Qt provides several custom event sources to
the Glib event loop. The bug (busy loop) was caused by faulty event
source implementation when QEventLoop::ExcludeUserInputEvents is set.
As long as the window system's event queue was not empty, we signaled
to the event dispatcher that there is an event ready to be dispatched.
This results in the dispatcher calling the relevant dispatch function
(which does handle the ExcludeUserInputEvents flag correctly). As we
do not dispatch user events, the window system's event queue never
becomes empty and we enter a busy loop (CPU running at 100%) where we
signal that we have events to dispatch, but we actually do not dispatch
them and g_main_context_iteration never gets to block.
This busy loop can cause blocking GTK functions such as gtk_dialog_run()
never return.
Task-number: QTBUG-59760
Task-number: QTBUG-57101
Change-Id: I545b7951108eeaba019614ae8f5a1168c8b26c27
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Gunnar Sletta <gunnar@crimson.no>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reflects QWidget API, and restores some behavior from Qt4.
Some WM can have several state at the same time. On Plasma for example,
when a window is both maximized and minimized, the "maximized" checkbox
is checked from the taskbar entry.
The API of QPlatformWindow was changed to take a QFlag and the platform
plugins were adapted.
- On XCB: Always send the full state to the WM. And read the full state.
- On Windows: The code was originally written with '&' in Qt4, and was changed
to == when porting. Some adaptation had to be made so the states would be
preserved.
- On macOS: Only a single state can be set and is reported back for now,
with the possibly to expand this in the future.
- Other platforms: Just do as before with the effective state.
Task-number: QTBUG-57882
Task-number: QTBUG-52616
Task-number: QTBUG-52555
Change-Id: I7a1f7cac64236bbd4c591f796374315639233dad
Reviewed-by: Gunnar Sletta <gunnar@crimson.no>
Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
|
|
|
|
|
|
|
|
|
|
| |
The previous logic relied on QPlatformWindow::setWindowState() being
synchronous and delivering the QPA event before returning to QWindow,
in which case window->windowState() would still refer to the old
state. Async platforms can now report the previous state correctly.
Change-Id: Ib9148fe23fb62be55b7e3a0ccf63d32c71dc2ad3
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that notification callbacks are delivered directly to QCocoaWindow,
it doesn't make sense to then send them to QPA via QNSView. By skipping
the QNSView roundtrip we also enable window state notifications for
foreign windows.
As an optimization we no longer flush all window system events, but use
the new synchronous API to deliver the window state change event.
Change-Id: I529b625fbe22e664c34a51bcd4448d1bf0392e6b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure
configure.pri
examples/widgets/painting/fontsampler/mainwindow.cpp
examples/widgets/painting/fontsampler/mainwindow.h
mkspecs/features/moc.prf
src/corelib/global/qglobal.h
src/gui/text/qtextdocument.cpp
Change-Id: Ica65512e00871695190a14ccea5c275b0165f787
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several people agreed that the name was confusing and that this one
is better.
Task-number: QTBUG-54616
Change-Id: I31cf057f4bc818332b0551a27d1711599440207c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Sune Vuorela <sune@vuorela.dk>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The contact patch of a finger on a touchscreen tends to be roughly
elliptical. If we model it as a QRectF, it's not clear whether the
ellipse should be considered to be inscribed in the rectangle and then
rotated, or whether the rectangle represents the outer bounds of the
rotated ellipse. In practice, since most touchscreens can't measure
rotation, it is effectively the latter. But modeling it that way means
information is lost if the touchscreen can measure rotation: you can
determine the bounds of a rotated ellipse, but you cannot derive the
rotated ellipse from its bounds. So it's better to model the axes
of the ellipse explicitly. This has the added benefit of saving a
little storage space: we replace 3 QRectF instances, whose width
and height will normally be the same, with 3 positions (bringing the
total to 12 QPointF's) and one set of axes. Further, most applications
only care about the center of each contact patch, so it's better to
store that explicitly instead of calculating QRectF::center() repeatedly.
In the past there may have been an assumption that the width of the rect is
the same as the horizontalDiameter of the ellipse, so the rect could be
considered to be rotated, and the ellipse to be inscribed. But in
d0b1c646b4a351f7eea2137c68993ae63b2b6bab and
40e4949674eaf7ceb09f6d18479ead1a36b384fd the point was made that the rect
is actually the bounding box of the rotated ellipse.
[ChangeLog][QtGui][QTouchEvent] TouchPoint::rect(), sceneRect() and
screenRect() are deprecated; a touchpoint is now modeled as an ellipse,
so please use pos(), scenePos(), screenPos(), horizontalDiameter()
and verticalDiameter() instead.
Change-Id: Ic06f6165e2d90fc9d4cc19cf4938d4faf5766bb4
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
QPointF & global -> QPointF &global
Change-Id: I35e54ad190bb35662abde59e786a0327c83806b7
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
Use “window” everywhere instead of “w”.
Change-Id: I4d5d4348906528be0138a4116de38ffc544f3c7b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|/
|
|
|
|
|
|
| |
“tlw” suggests that the API accepts top-level QWindows
only, which is not the case. Use “window” instead.
Change-Id: I9f58c638c33b33c3333c52a3cf291f311d799fe2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By using the SynchronousDelivery specialization instead of flushing all
window system events, we remove the risk of flushing an event that was
added without our knowledge.
For example, QGuiApplicationPrivate::processMouseEvent() used to prepend
a mouse move event to the QPA queue, which is why we had a check for
QWidgetWindow when flushing geometry changes. processMouseEvent no longer
sends the move event via the QPA queue, so that's no longer an issue,
but if it were to be reintroduced, we wouldn't need to check for
QWidgetWindow, as we're not flushing all events anymore.
Change-Id: Ib346ea9501cd88ddda6c2137981d3eb0922192a0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The setSynchronousWindowSystemEvents() API of QWindowSystemInterface is
supposed to be set globally by the platform plugin, not switched on and
off to trigger async/sync deliver of events for a specific event.
We introduce processWindowSystemEvent() in QWindowSystemInterfacePrivate
to match postWindowSystemEvent(), where the former is synchronous and
the latter is asynchronous.
This is then coupled with a templated version of handleWindowSystemEvent()
that then calls out to one of the two depending on the specialization
that's used. The default specialization will decide based on the state
set by setSynchronousWindowSystemEvents(), as before.
This allows templated versions of handleMouseEvent, handleKeyEvent, etc
to be added without maintaining two code paths, one for synchronous
and one for asynchronous delivery, which in the end allows us to
get away from using setSynchronousWindowSystemEvents() as a temporary
switch to synchronous mode.
The templates are defined in the QWindowSystemInterface source file,
with explicit instantiations of the three supported modes of delivery,
as having the definition in the header file would both require inlining,
as well as qwindowsysteminterface.h having access to the private parts
of QWindowSystemInterfacePrivate for the template function bodies.
Task-number: QTBUG-56274
Change-Id: I54c34da1ad90ff243f11905529874695f556cfcd
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
qmake/doc/src/qmake-manual.qdoc
src/corelib/global/qglobal.cpp
src/corelib/tools/qstring.cpp
src/network/socket/qabstractsocket.cpp
src/network/socket/qnativesocketengine_unix.cpp
src/plugins/platforms/eglfs/api/qeglfsglobal.h
Change-Id: Id5dfdbd30fa996f9b4b66a0b030b7d3b8c0ef288
|
| |\
| | |
| | |
| | | |
Change-Id: I1a63523de158757964b6fb5ea026cf69a6c5ddcf
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
26238aca8c442736f380eb523ef48468f892bdb7 causes double deletion of the
QTouchDevice in case the post routine already cleaned up the list by the
time the touch handler gets to do it.
Just check the list of devices to see if the one we hold is still there.
If not, the pointer is likely to be a dangling one so do nothing.
This will avoid dying with bus error or similar on application exit.
Task-number: QTBUG-51562
Change-Id: I50c1edee7405aad308274538219698388c2cc9f9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The new modular configuration system requires one global
header per module, that is included by all other files in
this module.
A similar scheme and naming convention is already being used
for many other modules (e.g. printsupport, qml, quick).
That header will later on #include the configuration file
for Qt Gui. For now it defines the Q_GUI_EXPORT macro for
this library.
In addition, add a private global header, qtguiglobal_p.h,
that can later on include the private config header for
Qt Gui for things we don't want to export to the world.
Change-Id: Id9ce2a4f3d2962c3592c35e3d080574789195f24
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
config_help.txt
configure
mkspecs/features/uikit/sdk.prf
src/corelib/global/qhooks.cpp
src/corelib/io/qfilesystemwatcher.cpp
src/corelib/io/qlockfile_unix.cpp
src/corelib/tools/qalgorithms.h
src/gui/kernel/qwindowsysteminterface.h
src/gui/text/qtextdocument_p.cpp
src/network/access/access.pri
src/network/access/qnetworkaccessmanager.cpp
src/network/access/qnetworkreplynsurlconnectionimpl.mm
src/src.pro
src/testlib/qtestcase.cpp
src/widgets/kernel/qwidgetbackingstore_p.h
src/widgets/styles/qwindowscestyle.cpp
src/widgets/styles/qwindowsmobilestyle.cpp
tests/auto/corelib/io/qdiriterator/qdiriterator.pro
tests/auto/corelib/io/qfileinfo/qfileinfo.pro
tests/auto/gui/kernel/qwindow/BLACKLIST
tests/auto/widgets/dialogs/qfilesystemmodel/tst_qfilesystemmodel.cpp
tools/configure/configureapp.cpp
Change-Id: Ibf7fb9c8cf263a810ade82f821345d0725c57c67
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
configure
mkspecs/macx-ios-clang/features/default_pre.prf
mkspecs/macx-ios-clang/features/sdk.prf
mkspecs/unsupported/freebsd-g++46/qplatformdefs.h
src/widgets/styles/qgtkstyle.cpp
tests/auto/corelib/io/qdiriterator/qdiriterator.pro
tests/auto/corelib/io/qfileinfo/qfileinfo.pro
Change-Id: Ia943555d1e59234a66f7dc65bdfda838e40001b5
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This gets included by Qt Wayland and will cause warnings there.
Change-Id: I3bb470d42ace4e6195d33019f81fa72f3006fc7f
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
TUIO supports tracking tagged physical objects on touchscreens by
various means (QR codes, RFIDs etc.) It can detect both position
and rotation. Likewise, it may be possible for some touchscreens or
drivers to detect orientation of the fingers. So, just as QTabletEvent
has rotation, each touchpoint needs to include the rotation value.
When using tokens, each object has a permanent unique ID, whereas
QTouchEvent::TouchPoint::id() is a transient ID which usually auto-
increments each time a finger is pressed to the device. So we need to
make that available too, to identify each token. Different platforms
may use different kinds of IDs (int, UUID, QR code etc.); however for
TUIO 1.x, the unique IDs are just 32-bit integers. QPointerUniqueId
is added, storing only a qint64 for now (like QTabletEvent::uniqueId())
but able to be expanded as necessary later on.
Task-number: QTBUG-51844
Change-Id: I04182042f47fa2954728079139a4664a31184b54
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some consumers of wheel events need to know if the
scrolling direction is inverted in order to provide
consistent behavior.
For example, the scrolling direction of a horizontal
slider should not change when the user toggles the
"natural scrolling" setting on OS X. In this case
the inverted bit will change state and the slider
can compensate.
This change adds a bit to QWheelEvent and sets it
on OS X.
Task-number: QTBUG-35972
Change-Id: I221435dea45d436d570b113bd0e24ee6f6832211
Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
tests/auto/corelib/io/qprocess/tst_qprocess.cpp
Change-Id: Ib6955eb874b516b185b45d6c38cec646fbaa95f4
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This issue is reproducible on OS X when using a Magic Mouse
or a combination of Magic Trackpad and regular mouse. In these
cases it's possible to start a scrolling gesture on one widget
and move the mouse cursor over another widget.
Although we send the wheel event phase information, we never
made any use of it. This means that a widget would start
scrolling even though it never received a ScrollBegin event.
In this patch, we make sure the scrolling cycle is respected
and that once a widget starts scrolling, it'll be recieving
all the wheel events until a ScrollEnd event reaches the
application.
For those input devices not supporting a proper phase cycle,
we introduce a new (undocumented) phase value, NoScrollPhase.
If the wheel event phase is NoScrollPhase, then we ignore
the current scroll widget and proceed as usual. This value
is the default for wheel events. It's up to the platform
plugin to set the proper phase value according to the data
received from the OS.
Finally, we fix a few of QWheelEvent constructors to properly
initialize the phase and source properties.
Task-number: QTBUG-50199
Change-Id: I3773729a9c757e2d2fcc5100dcd79f0ed26cb808
Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
|
|/
|
|
|
|
|
|
|
|
|
| |
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
Allow setting tryShortcutOverride for handleExtendedKeyEvent
with no timestamps.
Change-Id: I469b144cfcaf063861debe86195e1f96ac94cc37
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 7f5b94b47 moved shortcut handling into QGuiApplication (for all
platforms except OS X), due to crashes on Android where the events are
delivered from another thread.
Now that we have synchronous event delivery (also across threads) from
QPA, this is no longer needed, and we can move the code back to QPA,
where the platform has more control over when and how shortcut events
are delivered in relation to normal key events.
Handling shortcuts is as before a two step process. We first send a
QKeyEvent::ShortcutOverride event to the active window, which allows
clients (widgets e.g.) to signal that they want to handle the shortcut
themselves. If the override event is accepted, we treat it as the
shortcut not being handled as a regular shortcut, and send the event
as a key press instead, allowing the widget to handle the shortcut.
If nothing accepted the shortcut override event we pass it along to
the global shortcut map, which will treat the event as handled if
an exact or partial match is found.
The QShortcutMap::tryShortcutEvent() and nextState() implementation
has been simplified to not use the events accepted state for its
internal operation, which removes the need for saving the state
of the incoming event.
The QKeyEvent::ShortcutOverride event was also always sent with
the accepted state set to false, by calling ignore() on it before
sending it. This is now explicit by having shortcut override
events being ignored by default in their constructor, and the
documentation has been updated accordingly.
Change-Id: I9afa29dbc00bef09fd22ee6bf09661b06340d715
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Christian Stromme <christian.stromme@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that the values and signals reported by QInputDeviceManager
for touch devices always have corresponding entries in the list returned
by QTouchDevice::devices().
It also adds proper QTouchDevice unregistration when the underlying
input device gets removed by the evdevtouch QPA plugin.
Change-Id: I7bdf2f7435c775d15bddce8ba1e731afdc1d948a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
|
|
|
|
|
|
| |
Change-Id: Ie85a4e987eb069d4dd0dbd39860f299a7204b585
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flushWindowSystemEvents() now returns whether the
most recent event added to the queue was accepted
by Qt or not.
Use QAtomicInt to store the accepted state in order
to avoid a data race on it between the Gui thread
and the event poster thread.
Change-Id: I6c111fdaecda5c514307ca0749a54075fe8e872f
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
Set the accepted bit on the QWindowsystemInterface
keyboard event after processing the key event.
Change-Id: I2d8c9382f14840e464153870dff909000e64ddcd
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
doc/global/qt-cpp-defines.qdocconf
src/3rdparty/forkfd/forkfd.c
src/corelib/codecs/qtextcodec.cpp
src/corelib/kernel/qmetatype.cpp
src/corelib/tools/qset.qdoc
src/gui/accessible/qaccessible.cpp
src/gui/image/qpixmapcache.cpp
src/opengl/qgl.cpp
src/tools/qdoc/generator.cpp
src/widgets/kernel/qwidget.cpp
tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp
Change-Id: I4fbe1fa756a54c6843aa75f4ef70a1069ba7b085
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since d7ca800a87a2291c94c6580f0cfe068bb2280caf the shortcut events were
only sent once. The one sent by QGuiApplication did not create a
QKeyEvent with the full native modifier state - basically the extended
key event expected everywhere.
That means that shortcuts on some keyboard layouts - like ctrl-shift-7 on
the German keyboard (resulting in ctrl+/) - would not work when the
shortcut override was tested from QGuiApplication, but then the same shortcut was
sent from QApplication with the full information, so it worked the
second time. Shortcuts of this type in Qt Quick were broken before.
Task-number: QTBUG-47062
Change-Id: I8390b9a96d0d998a2a538ac65503702e0d299cc7
Reviewed-by: Andy Shaw <andy.shaw@theqtcompany.com>
Reviewed-by: Gatis Paeglis <gatis.paeglis@digia.com>
|
|/
|
|
|
|
|
|
|
|
| |
"WindowsSystem" -> "WindowSystem".
Strictly a QPA API break; there are no users of the
function in QtBase.
Change-Id: If2151b57587c68a7b5cbf261c54634aa930f2792
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is analogous to 0a92295ca829a62125c9f122fd3daec991993855
which added QMouseEvent::source.
For now, we say that a wheel event is synthetic when it comes from
a trackpad or other device that provides scrolling by some means
other than an actual wheel.
Change-Id: I0452ca2080b551b18b9c2f6e42db925d14ae339e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of sending the event from random places, send it from
QWindowSystemInterface. This allows to send override events on OS X to
menus before doing other key processing and reduces the number of
ShortcutOverride events on all platforms to exactly one per key press
event.
Additional test by Friedemann Kleint.
Task-number: QTBUG-38986
Change-Id: I6981bb776aba586ebc7c3daa5fd7a0d84c25bc3e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Add a QEventLoop::ProcessEventsFlags argument to
flushWindowSystemEvents(). This gives the platform
plugins more control over which events to flush.
Task-number: QTBUG-39842
Change-Id: Id9c01948b22e297b22503d38ec4e726f9f880fd5
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Reviewed-by: Jonathan Liu <net147@gmail.com>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL
Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updating the geometry and available geometry in two steps means that
QScreen will be in an inconsistent state when emitting the geometry
change signal, as the available geometry has not been updated yet.
Piggy-backing changes to the availableGeometry based on the virtual
geometry changing does not make sense, so we now tie geometry and
availableGeometry (and their size variants) to their own separate
geometryChanged and availableGeometryChanged signals.
Change-Id: Iee0ced642cbb91c470cb54bc507d2c0512482c13
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QExposeEvent::region() reports a region in a random coordinate system.
The behavior is undocumented and the platform plugins do different things.
xcb, offscreen and ios are correct. These set the region in local coordinates,
which is the most logical interpretation of the expose region.
windows is almost correct, except for one occurrence.
cocoa and others need changes: passing in geometry() as the exposed region is
always wrong.
The patch documents the expected behavior both for QExposeEvent and
internally in QWindowSystemInterface. The problematic plugins are fixed to
use local coordinates.
Task-number: QTBUG-40470
Change-Id: I6ded3154d14254fa71d4292d8e1b5e6cf696c81a
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, it has been necessary for tablet-oriented applications which
care about multi-button styli to reject each tablet event and wait for
the mouse event in order to know which buttons are pressed. This patch
adds the new API and also the X11/xcb implementation.
[ChangeLog][QtCore][Tablet support] Added buttons to QTabletEvent
Task-number: QTBUG-39458
Change-Id: If2c9ec1ceacc1700a82686c5fc6f568f9111055a
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently a click on e.g. the dock icon is not propagated to the
application so if for example the main widget is hidden, it can't be
brought back. Also neither applicationDidBecomeActive nor
applicationDidResignActive do anything. This patch fixes it
[ChangeLog][QPA][OS X] Add support for ApplicationState capability.
Application can now detect when an application states has changed
as well when the dock icon has been clicked.
Task-number: QTBUG-10899
Change-Id: I53d3e6eed4adc62b343e7aa3e3d8068d3248e7df
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Make sure that resize events are delivered when the platform
plugin overrides the geometry set in setGeometry().
This fixes a race condition where a widget was resized to its
sizeHint() while the window was maximized, and the content was
shown scaled on the screen.
The problem is that the widget gets the wrong size from
QWidget::setWindowState() (which calls adjustSize() in order to support
normalGeometry). This size is used to resize the backingStore. When the
QWindow is resized, it calls QEglFSWindow::setGeometry() which corrects the
size to screen()->availableGeometry(), and triggers a GeometryChangeEvent
since the size was corrected.
This ends up in QGuiApplicationPrivate::processGeometryChangeEvent() which
will not send a resize event, since the size has not changed (it is always
availableGeometry()). Therefore the widget is never resized, and the
backingStore remains the wrong size.
Task-number: QTBUG-34421
Change-Id: Iee49c53cc529de36010db2695d838d8c2284edd4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|\|
| |
| |
| | |
Change-Id: Ie56539b2e0be611a363b5f15ae5412a78d6945a2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add QWindowSystemInterface::GestureEvent and
QNativeGestureEvent to QtGui. These events are copies
of Qt4's QNativeGestureEvent, where it was an implementation
detail of QGestureManager.
Add gesture message handlers to QNSView and bring
back the Mac gesture recognizers for QGestureManager.
Task-number: QTBUG-28126
Change-Id: I1304e09e776fa7c44d133d54ca8b895ca2f544c5
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make platform plugins, like the windows one, able to indicate
if a mouse event is synthesized from a touch event by the OS.
This will be valuable information for the Quick2 event handlers.
No new member variables are added to QMouseEvent. Instead, the enum
value is encoded in the caps member, there are plenty of bits
available in it.
This introduces Qt::MouseEventSource and QMouseEvent::source() as
public APIs.
Change-Id: If087a0bafb33a6cd7891bd07b84871358f6aba69
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The responsibility of sendWindowSystemEvents() is to process events from
the window system. Historially that logic was part of the QPA/QWS event
dispatcher, which naturally also sent posted events. Through refactoring,
the code at some point ended up in in the QWindowSystemInterface class,
still with the posting of events in place.
This resulted in QPA event dispatchers adopting a pattern of just calling
sendWindowSystemEvents(), as that would cover both posted and window system
events. Other event dispatchers would call sendWindowSystemEvents(), and
then use a base-class implementation from QtCore for processing events,
resulting in two calls to QCoreApplication::sendPostedEvents() per
iteration of processEvents(). This breaks the contract that processEvents
will only process posted events that has been queued up until then.
We fix this entanglement by removing the sendPostedEvents() call from
QWindowSystemInterface::sendWindowSystemEvents() and move it to the
respective event dispatchers. For some EDs it means an explicit call
to sendPostedEvents, while others were already doing sendPostedEvents
though a separate source (GLib), or using a base-class (UNIX/BB), and
did not need an extra call.
We still keep the ordering of the original sendWindowSystemEvents()
function of first sending posted events, and then processing any
window system events.
Task-number: QTBUG-33485
Change-Id: I8b069e76cea1f37875e72a034c11d09bf3fe166a
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
|
|
|
|
|
| |
Change-Id: I4d8e7d48497d0d96a297191976c0d99feb67b538
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
|