summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qwindowsysteminterface.h
Commit message (Collapse)AuthorAgeFilesLines
* Propagate application termination requests through QPATor Arne Vestbø2019-10-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Instead of having each platform plugin deal with application termination in their own weird ways, we now have a QPA API to signal that the system requested the application to terminate. On the QGuiApplication side this results in a Quit event being sent to the application, which triggers the default behavior of closing all app windows, and then finally calling QCoreApplication::quit(). The quit event replaces the misuse of a close event being sent to the application. Close events are documented as being sent to windows. The close events that are sent to individual windows as part of the quit process can be ignored. This will skip the final quit() of the application, and also inform the platform that the quit was not accepted, in case that should be propagated further. In the future the logic for closing windows should be unified between the various approaches in closeAllWindows, shouldQuit, and friends. Change-Id: I0ed7f1c0d3f0bf1a755e1dd4066e1575fc3a28e1 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Modernize QWindowSystemInterface::handleCloseEventTor Arne Vestbø2019-10-041-1/+1
| | | | | | | The base WindowSystemEvent has had an eventAccepted flag since 2014. Change-Id: Ia0aa795083cd98ece83a4c1cc010d3a25e2489fd Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Merge remote-tracking branch 'origin/5.13' into devFriedemann Kleint2019-03-261-0/+4
|\ | | | | | | Change-Id: I38389a69411f4549fed432f1181dbe23398b34a2
| * Move screen maintenance functions from QPlatformIntegration to QWSITor Arne Vestbø2019-03-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QWindowSystemInterface is the de facto API for any plumbing going from the platform plugin to QtGui. Having the functions as protected members of QPlatformIntegration was idiosyncratic, and resulted in awkward workarounds to be able to call the functions from outside of the QPlatformIntegration subclass. The functions in QPlatformIntegration have been left in, but deprecated so that platform plugins outside of qtbase have a chance to move over to the new QWSI API before they are removed. Change-Id: I327fec460db6b0faaf0ae2a151c20aa30dbe7182 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | Widen out parameter "result" of the native event filters for Qt 6Friedemann Kleint2019-03-221-0/+4
|/ | | | | | | | | LRESULT on Windows 64 is a 64bit type, adapt filter functions of QAbstractNativeEventFilter and QAbstractEventDispatcher accordingly. Fixes: QTBUG-72968 Change-Id: Ie53193e355f0b8e9bd59fa377f43e2b4664a2ded Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* xcb: respect QEventLoop::ExcludeUserInputEvents in native event handlersGatis Paeglis2018-10-161-0/+1
| | | | | | | | | | | | | | | | | This was a regression from Qt 4. Before this patch, we supported filtering events only at QWindowSystemInterface level, but to properly support filtering in QAbstractEventDispatcher::filterNativeEvent, we have to filter the events earlier. Now it is possible to enable/disable this feature for platforms that support native event filtering. The mapping of which events are user input events were taken from QWindowSystemInterfacePrivate::EventType. Task-number: QTBUG-69687 Change-Id: I9a5fb9f999451c47abcdc83fdcc129b5eeb55447 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-06-071-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/corelib/kernel/qeventdispatcher_cf.mm src/gui/kernel/qguiapplication_p.h src/gui/kernel/qwindowsysteminterface.cpp src/gui/kernel/qwindowsysteminterface.h src/plugins/platforms/cocoa/qcocoawindow.mm src/plugins/platforms/cocoa/qnswindowdelegate.mm src/plugins/platforms/ios/qioseventdispatcher.mm src/plugins/platforms/windows/qwindowsdrag.h src/plugins/platforms/windows/qwindowsinternalmimedata.h src/plugins/platforms/windows/qwindowsmime.cpp src/plugins/platforms/winrt/qwinrtscreen.cpp Change-Id: Ic817f265c2386e83839d2bb9ef7419cb29705246
| * Make sure we can build with -no-feature-draganddropJoerg Bornemann2018-05-291-1/+1
| | | | | | | | | | | | | | | | | | We move QInternalMimeData to a separate file, because this class is used, even if draganddrop is disabled. From now on, include qinternalmimedata_p.h instead of qdnd_p.h for QInternalMimeData. Change-Id: I594e08e2e90d574dc445119091686b4b69e4731b Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-05-081-0/+1
|\| | | | | | | | | | | | | | | Conflicts: src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp tests/auto/corelib/io/qresourceengine/qresourceengine_test.pro Change-Id: I3169f709cc2a1b75007cb23c02c4c79b74feeb04
| * QtGui: Enable synchronous delivery for QWSysIf:::WindowScreenChangedEventFriedemann Kleint2018-05-081-0/+1
| | | | | | | | | | | | | | Task-number: QTBUG-67777 Change-Id: I6d52b650fb33283010ef06259da83cdb2fd3483f Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | qpa: improve API to support DnDs from other processesGatis Paeglis2018-05-041-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... instead of using a hack of directly accessing QGuiApplication members. The current QPA API was bad for two reasons: 1) It expects platform plugin authors to know about internals of Qt Gui, particularly that QGuiApplication uses QGuiApplication::{mouseButtons,keyboardModifiers} to construct QDragMoveEvent and QDropEvent events. Which results in the second reason why this is bad. 2) Platform plugins should not directly access member variables of QGuiApplication, just to make sure that QDragMoveEvent and QDropEvent events contain correct state. Platform plugins should instead use QWindowSystemInterface to communicate with Qt Gui (which is also the solution here). The solution is to extend QWindowSystemInterface::handle{Drag,Drop} to require mouse/keyboard state. We already do this for some of the other methods, so it is nothing extraordinary. This type of interface is also _required_ to support drag-n-drops from other processes. We can't use QGuiApplication::{mouseButtons,keyboardModifiers} when the drag originates from another process, instead we need to query mouse/keyboard state from the system. This patch fixes drag-n-drops from others processes on XCB platform plugin. Task-number: QTBUG-57168 Change-Id: I3f8b0d2f76e9a32ae157622fef801829d629921d Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | Support synchronous handleCloseEvent()Morten Johan Sørvig2018-02-211-0/+1
|/ | | | | | | | Use QT_DEFINE_QPA_EVENT_HANDLER to define QWindowSystemInterface::handleCloseEvent(). Change-Id: I4f1105f7aa78bdebddfe9062b388eb616e325e31 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Merge remote-tracking branch 'origin/5.10' into devLars Knoll2018-01-021-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf sc/corelib/io/qfsfileengine_p.h src/corelib/io/qstorageinfo_unix.cpp src/platformsupport/eglconvenience/qeglpbuffer_p.h src/platformsupport/input/libinput/qlibinputkeyboard.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/plugins/platforms/cocoa/qcocoamenu.mm src/plugins/platforms/ios/qiosscreen.h src/plugins/platforms/ios/qioswindow.h src/plugins/platforms/ios/quiview.mm src/printsupport/dialogs/qpagesetupdialog_unix_p.h src/printsupport/dialogs/qprintpreviewdialog.cpp src/printsupport/widgets/qcupsjobwidget_p.h src/widgets/widgets/qmenu.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: Iecb4883122efe97ef0ed850271e6c51bab568e9c
| * Merge remote-tracking branch 'origin/5.9' into 5.10Lars Knoll2017-12-301-0/+3
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf mkspecs/win32-g++/qmake.conf src/corelib/global/qglobal_p.h src/corelib/global/qoperatingsystemversion_p.h src/corelib/io/qfilesystemengine_win.cpp src/network/bearer/qbearerengine.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/sql/doc/snippets/code/doc_src_sql-driver.cpp src/widgets/kernel/qwidget_p.h src/widgets/kernel/qwidgetwindow.cpp src/widgets/styles/qfusionstyle.cpp tests/auto/corelib/io/qfileinfo/tst_qfileinfo.cpp Change-Id: I80e2722f481b12fff5d967c28f89208c0e9a1dd8
| | * Teach QPlatformWindow about safe area margins and implement for iOSTor Arne Vestbø2017-12-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The safe area margins of a window represent the area that is safe to place content within, without intersecting areas of the screen where system UI is placed, or where a screen bezel may cover the content. QWidget will incorporate the safe area margins into its contents margins, so that they are are never smaller than the safe area margins. This can be disabled by unsetting the Qt::WA_ContentsMarginsRespectsSafeArea widget attribute, which is set by default. QLayouts will automatically use the contents area of a widget for their layout, unless the Qt::WA_LayoutOnEntireRect attribute has been set. This can be used, along with a contents margin of 0 on the actual layout, to allow e.g. a background image to underlay the status bar and other system areas on an iOS device, while still allowing child widgets of that background to be inset based on the safe area. [ChangeLog][iOS/tvOS] Qt will now take the safe area margins of the device into account when computing layouts for QtWidgets. Change-Id: Ife3827ab663f0625c1451e75b14fb8eeffb00754 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-11-301-0/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/thread/qsemaphore.cpp tests/auto/network/access/qnetworkreply/tst_qnetworkreply.cpp tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: Id35b535e88df63fdfe4007ea92ed4a39c4b6d707
| * | Merge remote-tracking branch 'origin/5.9' into 5.10Liang Qi2017-11-231-0/+1
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qstandardpaths_win.cpp src/plugins/platforms/ios/qioswindow.mm src/plugins/platforms/ios/quiview.mm tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: I5deb0a0176a454a9c566e924d074ba60ce04f0bc
| | * qpa: Teach handleApplicationStateChanged about sync/async deliveryTor Arne Vestbø2017-11-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using QWindowSystemInterface::SynchronousDelivery reduces the chance that we are flushing other events before delivering the application state change. Those other events may conclude that the application is still active, while in reality it is not, and do bad things. Change-Id: I738c162fac22d2cd18de1e080bcd2cda78ec3f77 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | | qpa: enhance mouse event with type and button dataGatis Paeglis2017-10-101-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and deprecate QWSI APIs that accepts mouse event without mouse button/ type data. In the early days of Qt5 it was decided to centralize mouse button/type handling in QGuiApplication (because of limitation of some now unknown platform). This has proven to be problematic as mouse handling details differ across platforms (e.g on X11 we do not receive mouse release event when closing popup windows or ordinary windows that are closed from the mouse press event). Instead of hacking around platform specific behaviors in Qt Gui, we should move this task back to platform plugins (similar to how this was done in Qt4 with native APIs sending mouse details directly to QApplication). There are even cases where it simply is not possible to deduce (from QGuiApplication) which button caused the event (e.g. when more than one button is involved and some event goes missing). Besisdes, throwing away information which is already available at QPA level (for free) and trying to deduce it again at Qt Gui level seems impractical, fagile (as probably noticed by people fixing all the unexpected issues) and adds unnecessary complexity. Note: Removing the deprecated QWSI APIs from offscreen plugin depends on fixing autotests that rely on QOffscreenCursor::setPos() logic. For the convenience of testing use QT_QPA_DISABLE_ENHANCED_MOUSE to restore to the old code path where QGuiApplication does the mouse state deducing. Other platforms have similar issues. I do not have all supported platform available on my desk, so other platform maintainers will need to take care of porting those platforms to the new APIs. And mainly, I don't want to deal with all the hacks that other platforms have added to workaround this broken mouse logic. In Qt6 we need to remove deprecated code path from QGuiApplication. This patch: - Extends QWindowSystemInterfacePrivate::MouseEvent ctor with QEvent::Type and Qt::MouseButton. We use this extra data when processing mouse events in QGuiApplication. This actually is similar to KeyEvent, where we do pass the type (press or release) to QtGui. - Refactors QGuiApplicationPrivate::processMouseEvent and qtestlib to use the new APIs. Task-number: QTBUG-59277 Task-number: QTBUG-62329 Task-number: QTBUG-63467 Change-Id: If94fd46a7cccfea8264dcb1368804c73334558b8 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* | | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-09-261-3/+3
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/gui/kernel/qguiapplication.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/plugins/platforminputcontexts/ibus/qibusplatforminputcontext.h src/plugins/platforms/cocoa/qcocoawindow.h src/testlib/qtestsystem.h Change-Id: I5975ffb3261c2dd82fe02ec4e57df7c0950226c5
| * | make the QTouchDevice available in each QNativeGestureEventShawn Rutledge2017-09-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QtQuick is beginning to have a use for this, to distinguish native gestures which come from actual trackpad rather than from the "core pointer". It might as well use a real device ID instead of making one up, as it has to do for the core pointer. So far on macOS, the device ID isn't a real one; but that can be fixed, as the qCDebug lines demonstrate (different trackpads have different IDs). Change-Id: I5841deb1c4cc0b77a3b1df70904f70b3d2d71853 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | Replace Q_NULLPTR with nullptr where possibleKevin Funk2017-09-191-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | Remaining uses of Q_NULLPTR are in: src/corelib/global/qcompilerdetection.h (definition and documentation of Q_NULLPTR) tests/manual/qcursor/qcursorhighdpi/main.cpp (a test executable compilable both under Qt4 and Qt5) Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* | Ensure all platforms send geometry events if request was not fulfilledTor Arne Vestbø2017-07-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic of deciding whether or not to send resize and move events has been centralized in QGuiApplication. This ensures that if a window with geometry 100,100+200x200 is moved and resized to e.g. 0,0+100x100, but the window manager denies the request (because the window would e.g. overlap with system UI), and issues a geometry update with the original geometry, 100,100+200x200, we will still treat that as warrant of a move/resize event to the application, so the application knows that its position and size is as before. [ChangeLog][Qt Gui][QPA] QWindowSystemInterfacePrivate::handleGeometryChange no longer takes the old geometry as an argument. Task-number: QTBUG-57608 Change-Id: I1d471cc7a257fef958bdb1e56184fa95489403a3 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-07-041-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qprocess_unix.cpp src/plugins/platforms/xcb/qxcbconnection.cpp src/plugins/platforms/xcb/qxcbwindow.cpp src/widgets/util/util.pri tests/auto/corelib/thread/qthread/qthread.pro tests/auto/corelib/thread/qthread/tst_qthread.cpp Change-Id: I5c45ab54d46d3c75a5c6c116777ebf5bc47a871b
| * Convert features.whatsthis to QT_[REQUIRE_]CONFIGStephan Binner2017-06-291-1/+1
| | | | | | | | | | | | | | Move feature definition to gui/configure.json Change-Id: I00b35c0e259d0a695d84a9bf6803eba74d41465a Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* | qpa: start using QT_DEPRECATED_SINCE to increase visibilityGatis Paeglis2017-06-021-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ... when platform plugins are using compatibility APIs. Even though QPA is not a public API and does not promise source/binary compatibility, we still try to not break things when possible. Eventually deprectated APIs will be dropped (e.g between major Qt versions). Having deprecation warnings here would help maintainers to notice API changes even before their code stops compiling due to removed QPA APIs. This will also ensure that we won't forget to remove compatibility APIs. Change-Id: If13786eb7d42a595708ace00b2ddea5209df18db Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-05-071-0/+1
|\| | | | | | | | | | | | | | | Conflicts: src/network/access/qnetworkreply.cpp tests/auto/corelib/kernel/qmetaobject/tst_qmetaobject.cpp Change-Id: Iadf766269454087e69fb216fc3857d85b0ddfaad
| * Prevent busy loop in glib event dispatcherGatis Paeglis2017-04-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | .. 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>
* | Make QWindow's windowState a QFlags of the WindowStateOlivier Goffart2017-03-161-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* qpa: Let platform plugins report old state for window state changesTor Arne Vestbø2017-02-151-1/+1
| | | | | | | | | | 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>
* macOS: Handle window state changes directly in QCocoaWindowTor Arne Vestbø2017-02-111-0/+1
| | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.8' into devLiang Qi2016-12-161-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | 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
| * rename QPointerUniqueId -> QPointingDeviceUniqueIdShawn Rutledge2016-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* | TouchPoint: add horizontalDiameter, verticalDiameter; deprecate rectsShawn Rutledge2016-12-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | QPA style cleanup: no space after ampersandMorten Johan Sørvig2016-12-021-8/+8
| | | | | | | | | | | | | | | | 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>
* | QPA: Consistent QWindow variable namesMorten Johan Sørvig2016-12-021-32/+32
| | | | | | | | | | | | | | Use “window” everywhere instead of “w”. Change-Id: I4d5d4348906528be0138a4116de38ffc544f3c7b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | QPA: Consistent QWindow variable namesMorten Johan Sørvig2016-12-021-2/+2
|/ | | | | | | | “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>
* iOS: Take advantage of new synchronous API for QPA event deliveryTor Arne Vestbø2016-10-141-3/+9
| | | | | | | | | | | | | | | | | | 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>
* Allow granular synchronous and asynchronous delivery of QPA eventsTor Arne Vestbø2016-10-101-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.7' into devLiang Qi2016-08-161-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | 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
| * Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-08-101-0/+1
| |\ | | | | | | | | | Change-Id: I1a63523de158757964b6fb5ea026cf69a6c5ddcf
| | * evdevtouch: Avoid crashing on exitLaszlo Agocs2016-08-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Add qtguiglobal.h and qtguiglobal_p.hLars Knoll2016-07-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge remote-tracking branch 'origin/5.7' into devLiang Qi2016-06-131-2/+2
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-06-101-2/+2
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| | * Fix zero-as-null-pointer-constant in wayland compositor apiAllan Sandfeld Jensen2016-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | QTouchEvent: add uniqueId and rotation; TUIO: support fiducial tokensShawn Rutledge2016-04-071-1/+4
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Add QWheelEvent::inverted()Morten Johan Sørvig2016-03-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-02-291-2/+10
|\| | | | | | | | | | | | | Conflicts: tests/auto/corelib/io/qprocess/tst_qprocess.cpp Change-Id: Ib6955eb874b516b185b45d6c38cec646fbaa95f4
| * Track target widget when wheel events are receivedGabriel de Dietrich2016-02-291-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-09 20:25:37 +0000