summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qguiapplication.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove conditioning on Android embeddedEdward Welbourne2021-09-171-3/+3
| | | | | | | | It is no longer handled separately from Android. This effectively reverts commit 6d50f746fe05a7008b63818e77784dd0c99270a1 Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Deduplicate maybeQuitOnLastWindowClosed handlingTor Arne Vestbø2021-09-171-3/+27
| | | | | | | | | | | | | | | | | | The functionality now lives in QGuiApplication, and is triggered by QGuiApplication and QApplication after dispatching the close event to the window. The slight difference between how a Qt GUI and Qt Widget app determines if a window should contribute to the close-on-quit behavior has been abstracted into a QWindowPrivate helper. The additional checks that were in place for skipping out of the whole maybeQuitOnLastWindowClosed machinery have been kept. Task-number: QTBUG-53286 Change-Id: I81bd474755f9adb3a2b082621e5ecaa1c4726808 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix QGuiApplication command line options documentation for X11Tor Arne Vestbø2021-09-171-3/+3
| | | | | | | Fixes: QTBUG-96600 Pick-to: 6.2 5.15 Change-Id: Ic3670b952d97270cce4f0a8df8bba79e934e4a6d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use wayland platform plugin on GNOME wayland sessions by defaultJan Grulich2021-09-091-15/+1
| | | | | | | | | | | Qt wayland platform plugin has improved quite a lot and it is now pretty much usable on Gnome. It also improves user experience a lot on HiDPI displays. Pick-to: 6.2 Change-Id: I943e0bb969f384bdc3c603e290ce9c8358b70f63 Reviewed-by: Aleix Pol Gonzalez <aleixpol@kde.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QGuiApplication: move two static variables from DATA to BSSMarc Mutz2021-08-101-2/+2
| | | | | | | | | | | | | | | | | The {mouse,touch}DoubleXDistance variables were initialized to -1, which forces them into the DATA segments. But this value is completely unused, since these variables are also set in initThemeHints(), called from QGuiApplicationPrivate::init(), before their only user, QGuiApplicationPrivate::processMouseEvent(), can possibly execute. By changing the default value to 0, then, we allow the compiler to place these variables into the BSS segment. Change-Id: I86144559ee2410b844f70a4f2499c8d3140d14cf Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Add native interface for X11 application, exposing display and connectionTor Arne Vestbø2021-08-061-0/+17
| | | | | | | | | | | | | | | | | | | | | The major use-case of the now private QX11Info from Qt X11 Extras was getting hold of the Xlib display and XCB connection, for example in KDE: https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=QX11Info A new native interface for QGuiApplication has now been added that exposes these two properties, e.g.: if (auto *x11App = app.nativeInterface<QX11Application>()) qDebug() << x11App->display() << x11App->connection(); To avoid type clashes one of the enum values of QXcbNativeInterface's ResourceType had to be renamed. Pick-to: 6.2 Task-number: QTBUG-93633 Change-Id: I2e366a2bb88bd3965ac6172ad000ae32209f43e7 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Improve WM_DPICHANGED handlingMorten Johan Sørvig2021-08-061-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Resize QPlatformWindow on DPI change, so that QWindow size can stay approximately constant. For example, a 100x100 QWindow at 100% scaling will have a 100x100 QPlatformWindow. If the scaling is changed to 200% then the QPlatformWindow is resized to 200x200, while the size of the QWindow stays at at 100x100. In practice the QWindow size will also change slightly, due to inaccuracies in how we adjust for the size of the non-client window area. This will be addressed in a later commit. We can get DPI change independently of screen change, so no resizing should happen in screen change events. Disable the resize code in QGuiApplication for Q_OS_WIN, and remove the WithinDpiChanged flag. The new flow for handling DPI change is: 1) Send screen change (if any), so that the correct screen will be used when calculating scale factors during the following resize. 2) Resize the native window, which will trigger geometry change events, possibly also for the QWindow. 3) Resize child windows; WM_DPICHANGED is sent to top-level windows only. Fixes: QTBUG-89294 Pick-to: 6.2 Change-Id: I0e2d44bae72d20ebdafc3d410db7be9964ad851b Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Doc: Ensure deprecated APIs in Gui are documented as suchNico Vertriest2021-07-261-2/+2
| | | | | | | | | | | Added missing #if-ery and deprecation macros to a QFont constructor that was only documented as deprecated. Fixes: QTBUG-94521 Fixes: QTBUG-95310 Pick-to: 6.2 6.1 Change-Id: I3d0418a3f7dca191a9068cc22627fe4deb7c53c5 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Use member function instead of template function to resolve native interfaceTor Arne Vestbø2021-07-171-3/+2
| | | | | | | | | | | | | | The use of a freestanding function is not needed now that the name doesn't alias the nativeInterface accessor function, and was just adding complexity to the machinery. People not familiar with the code will have an easier time following the flow through the helper member function, and we no longer need to declare our own export macros. Pick-to: 6.2 Change-Id: I17530b7e89939cfc19ab8ffaa076b7129ae02dcf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Rename QNativeGestureEvent::deltas() to delta(); clarify docsShawn Rutledge2021-07-141-1/+1
| | | | | | | | | | | | | | | | | In QPanGesture this is called delta(). OTOH we have QWheelEvent::pixelDeltas(). Delta is a vector, and there's only one (with two components). Native gestures hold incremental values: e.g. the pinch gesture event provides an incremental amount of either zooming or rotation (so most events have QNativeGestureEvent::value() very close to 0). It's the same with the pan gesture's delta(). Add better docs for swipe and pan gestures. Change-Id: Ia147c7c9a22e084c3700b1620dec46427d792bd1 Reviewed-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QColorTrcLut: hold in shared_ptrMarc Mutz2021-07-121-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | ... instead of raw pointers or QSharedPointer. Raw pointers are, of course, a no-no in modern code. In particular, when the result is then held in shared_ptr or QSharedPointer, make_shared or QSharedPointer::create() should be used to reduce number of memory allocations. Since this is private API, we're free to use std::shared_ptr, which does only half the atomic operations on copies, compared to QSharedPointer, so is more efficient. For either make_shared or QSharedPointer::create(), we need to work around the private ctor, which we do by inheriting a member-function local class from QColorTrcLut and make_shared'ing that. As a member-function-local class, it has access to the otherwise private parts of QColorTrcLut, including its default constructor. As a public subclass, shared_ptr has no problem performing the derived-to-base pointer adjustment in the return statement. This way, we can use make_shared even though our target's class' ctor is private. Change-Id: Icb11249b54cd5e544e692f6a0bf1f9dda1710454 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Deliver WindowActivate/Deactivate events to QWindowVolker Hilsheimer2021-06-111-1/+9
| | | | | | | | | | We need those events to trigger palette color group changes in QQuickItem without having to connect every item to yet another QWindow signal. Task-number: QTBUG-93752 Pick-to: 6.2 Change-Id: I8534808cdaab828e5876f8fda31567aeb1b4272a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: allow Qt::AA_DontShowShortcutsInContextMenus overridesVolker Hilsheimer2021-06-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Following the discussion in QTBUG-69452, the resulting change in cc33dd079796437bafed8f42de7fbf8f17d19ec8, and the documentation of QAction::shortcutVisibleInContextMenu, the intention is that the attribute allows the overriding of the platform default. However, QAction did ask both the attribute and the platform integration, making the override impossible. Instead, ask only the attribute, but default the value of the attribute to what the platform integration provides. [ChangeLog][QtGui][QAction] The shortcutVisibleInContextMenu property defaults to the value of the Qt::AA_DontShowShortcutsInContextMenus attribute, which in turn defaults to the platform integration. To override the default, set the application attribute after instantiating QApplication, or override the default for each QAction instance. Task-number: QTBUG-73990 Pick-to: 5.15 6.1 Change-Id: Iaba330913555d93d05efe1b3965a6aea39db5554 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Doc: Use \deprecated instead of \obsoletePaul Wicking2021-05-261-2/+2
| | | | | | Task-number: QTBUG-93990 Change-Id: I4e512354a49dde6678ca89cabc56bc76ba666bb3 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Type erase native interfaces via string instead of typeidTor Arne Vestbø2021-05-201-2/+2
| | | | | | | | | | The latter forces users to build with RTTI enabled, as the typeid use is in our public headers. Surprisingly this is also the case even without instantiating the relevant template. Change-Id: Icd18a2b85b250e0b77960797e5c43b7eaf9bd891 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Windows QPA: Fix dock widget drag&drop failureAndre de la Rocha2021-05-171-1/+1
| | | | | | | | | | | | | | | | | | | A previous change to fix QTBUG-85431 has caused this issue by emulating the behavior of the non-enhanced mouse event handler in a particular case, where mouse move events that did not change position were ignored. However, some of these events seem to be involved in the dock drag&drop implementation. This issue is also reproduced in pre-5.15 releases, predating the QTBUG-85431 fix, by disabling the enhanced mouse event handler by setting the QT_QPA_DISABLE_ENHANCED_MOUSE env var. However, the ignored events in the current issue seem to be non-client events only, while the QTBUG-85431 issue was related to client mouse events. So we can restrict the test added in the QTBUG-85431 fix and have both issues fixed. Fixes: QTBUG-92182 Pick-to: 5.15 6.0 6.1 Change-Id: I98c0c8597912c7f4fe58af375a5a560695a82746 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Rejig native interface plumbingTor Arne Vestbø2021-05-121-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The initial approach for providing public access to native interfaces via T::nativeInteface<I>() was based on the template not being defined, and then having explicit instantiations of the supported types in a source file, so that the accessors were exported and available to the user. This worked fine for "simple" types such as QOpenGLContext and QOffscreenSurface, but presented a problem in the context of classes with subclasses, such as Q{Core,Gui}Application. To ensure that a native interface for QCoreApplication was accessible both from QCoreApplication and its subclasses, while at the same time preventing a native interface for QGuiApplication to be accessible for QCoreApplication, the nativeInterface() template function had to be declared in each subclass. Which in turn meant specializing each native interface once for each subclass it was available in. This quickly became tedious to manage, and the requirements for exposing a new native interface wasn't very clear with all these template specializations and explicit instantiations spread around. To improve on this situation, while also squashing a few other birds at the same time, we change the approach to use type erasure. The definition of T::nativeInteface<I>() is now inline, passing on the requested interface to a per type (T, not I) helper function, with the interface type flattened to a std::type_info. The type_info requested by the user is then compared to the available types in a single per-type (T) "switch statement", which is a lot easier to follow for someone trying to trace the logic of how a native interface is resolved. We can safely rely on type_info being stable between the user application and the Qt library as a result of exporting the type info for each native interface, by explicitly ensuring they have a key function. This is the same mechanism that ensures we can safely dynamic_cast these interfaces, even across library boundaries. The use of a free standing templated helper function instead of a member function in the type T, is to avoid shadowing issues, and to not pollute the class namespace of T with the helper function. Since we are already changing the plumbing for how a user resolves a native interface for a type T, we take the opportunity to add a few extra safeguards to the machinery. First, we add a static assert in the T::nativeInteface<I>() definition, that ensures that only compatible interfaces, as declared by the interface themselves, are allowed. This ensures a compile time error when an incompatible interface is requested, which improves on the link time errors we had prior to this patch, and also offsets the one downside of type erasure, namely that errors are only caught at runtime. Secondly, each interface meant for public consumption through T::nativeInteface<I>() is declared with a revision, which is checked when requesting the interface. This allows us to bump the revision when we make breaking changes to the interface that would have otherwise been binary incompatible. Since the user will never see this interface due to the revision check, they will not end up calling methods that have been removed or renamed. One advantage of moving to a type-erased approach for the plumbing is that we're not longer exposing the native interface types as part of the T::nativeInteface symbols. This means that if we ever want to rename a native interface, the only exported symbol that the user code relies on is the type info. Renaming is then possible by just exporting the type info for the old interface, but leaving it empty. Since no class in Qt implements the old native interface, the user will just get a nullptr back, similarly to bumping the revision of an interface. Change-Id: Ie50d8fb536aafe2836370caacb22afbcfaf1712a Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Remove Qt6 switches from QtGuiAllan Sandfeld Jensen2021-05-051-4/+0
| | | | | | | Removing now dead code Change-Id: I021539da6517fdb8443f8ae9431fc172b7910cfc Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Call updateHighDpiScaling() on screenAdded()Morten Johan Sørvig2021-04-281-15/+0
| | | | | | | | | | | | | | | | | | | | | | QHighDpiScaling has two init/update functions: - initHighDpiScaling(): called once during QGuiApplication construction - updateHighDpiScaling(): called whenever (relevant) screen configuration changes Currently the calls to updateHighDpiScaling() are made from multiple places including platform code. Simplify by calling it from two locations: - QWindowSystemInterface::handleScreenAdded() - QGuiApplicationPrivate::processScreenLogicalDotsPerInchChange() Replace comment about early calls to qt_defaultDpi with a test which calls qt_defaultDpiX/Y with no screens attached. (Looking at the qt_defaultDpiX() implementation, it is unlikely that there will be a problem as long as updateHighDpiScaling() is called before QGuiApplication::primaryScreen() starts returning a non-null value.) Change-Id: I447db42894617495843a5cb531a1322b000fed62 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add storage for (pixel) deltas and fingerCount to QNativeGestureEventShawn Rutledge2021-04-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | It's not clear now whether trackpad gestures on Windows will need to be so different than on macOS; however, any reasonable int value can be stored in a qreal, and in Qt Quick we like to use floating-point numbers for all "real" values and measurements. So since we need to add more storage, and quint64 m_intValue has never been used, we now replace it with a QVector2D, which should have the same size. The intended use is that PanNativeGesture will include a displacement, probably in pixels, by which the viewport or some target item should be panned or moved. The naming of deltas() is flexible enough to support any gesture with some incremental 2D valuators, though, just as value() has gesture-dependent semantics. fingerCount() will be useful for Qt Quick pointer handlers to filter out events that have the wrong number of fingers, e.g. to require that either a 3-finger pan gesture or 3 individual touchpoints are required to activate DragHandler { minimumPointCount: 3 } (assuming we implement pan gesture support in DragHandler). Fixes: QTBUG-92179 Task-number: QTBUG-92098 Change-Id: I5462aea9047beed6e99075294a62011edd8a59f5 Reviewed-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* wayland: Remove bogus warning about ignoring WAYLAND_DISPLAYEskil Abrahamsen Blomfeldt2021-03-091-7/+18
| | | | | | | | | | | | | | | | | | On Gnome, we will not default to Wayland at the moment, even if the desktop is run in Wayland mode. In this case, we warn users that they can still select Wayland manually using QT_QPA_PLATFORM. Problem was: We never checked if they had actually explicitly selected Wayland, so even in the cases where we would end up using that QPA plugin, people would still see the warning. This moves the check to the end of the platform selection algorithm, after we have collected all the information. Pick-to: 6.0 6.1 Change-Id: I0d734bd0782c5e58d6dc63f69b7d531a479ad942 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QAbstractFileIconProvider: Use platform theme iconsFriedemann Kleint2021-02-211-0/+3
| | | | | | | | Add code paths to use platform theme icons should icon themes fail. Task-number: QTBUG-66177 Change-Id: I9554637f5230b1f57faaeef6b2c04cf082271edb Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QGuiApplication: use global position to create local position for synthetic ↵Richard Moe Gustavsen2021-02-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | mouse events When QWidgetWindow handles a QTouchEvent, it will call updateTouchPointsForWidget() for each widget it tries to deliver the touch event to. This will make sure that the point's position() is updated to be local to the widget being processed. The problem is that we never reset this overwriting of local positions in the event after we're done. So if we later try to synthesize a mouse event from it, the local position in the fake mouse event will be based on the local position inside a random widget, and not the original local position sent from QPA. Rather than trying to store all the original local positions inside the event before going through this delivery logic, and reset it afterwards, we base the local position of the synthesized mouse event on the (unmodified) global position instead. Fixes: QTBUG-90033 Change-Id: I1588351482de7cce9c06d102db3686ea8dd0c118 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* AA_SynthesizeTouchForUnhandledMouseEvents: keep correct coordinatesShawn Rutledge2021-01-141-1/+1
| | | | | | | | | | | | | | | | | | | | | QGuiApplicationPrivate::processMouseEvent() sends a QWindowSystemInterfacePrivate::TouchEvent if the mouse event is not accepted and AA_SynthesizeTouchForUnhandledMouseEvents is enabled. A QPA TouchEvent always contains native touch points, which is why it calls QWindowSystemInterfacePrivate::fromNativeTouchPoints to translate the QMouseEvent's device-independent position back to the raw position that it would have had if it came from a real touchscreen. Therefore we must give that function touchpoints that are actually in native coordinates. It may be that some of this transformation could be avoided entirely, but here we prove that the existing way works correctly, by adding coordinate checking to the tst_QWindow::mouseToTouchTranslation() test. Pick-to: 6.0 Task-number: QTBUG-86165 Change-Id: I4c9ca2b11e9eb76d79712c187db3eb9865da581a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* doc: Remove dpiawareness command line argumentTor Arne Vestbø2020-12-041-2/+0
| | | | | | | | | We don't want to (officially) expose customizations like this to the user, now that high-DPI is always enabled and should work. Change-Id: I2f0bd7c625b565896b0766586f191ff5001eb60a Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Fix documentation links to High DPI documentationAndreas Buhr2020-12-011-1/+1
| | | | | | | | | | | The documentation on High DPI was recently rewritten, renaming several sections. This patch fixes the links which were broken by this change. Task-number: QTBUG-88533 Pick-to: 6.0 Change-Id: I5e9417554270a6740986d7cec5e3433d043e5560 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Update setHighDpiScaleFactorRoundingPolicy docsTor Arne Vestbø2020-11-271-6/+3
| | | | | | | | | | | The default is now passthrough. And let's not mention the environment variable overrides, as they are meant for internal testing. Pick-to: 6.0 Pick-to: 6.0.0 Change-Id: Ie2409e5411d4bdcdf041834cb5ca9e1215aa173a Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* QGuiAppPriv: don't clear target and window for TouchCancelShawn Rutledge2020-11-211-2/+0
| | | | | | | | | | | | | It's nice not to leave garbage in QPointingDevicePrivate::activePoints between events; on the other hand, this garbage doesn't matter, because every press event sets the target and window independently, without caring what was stored there from before. But it was wrong to clear it before we've even delivered the TouchCancel event. Pick-to: 6.0 Pick-to: 6.0.0 Change-Id: I924039a7c7a8ed75f420d1837c63dc19d3cc98b6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Adjust code format, add space after 'if'Zhang Sheng2020-11-161-1/+1
| | | | | | Change-Id: Ice081c891ff7f4b766f49dd4bd5cf18c30237acf Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: hjk <hjk@qt.io>
* Silence "same window" warning when QPA doesn't give touch dest windowShawn Rutledge2020-11-101-6/+4
| | | | | | | | | | | | Platform plugins should dispatch events to specific windows when possible; but eglfs currently doesn't do that, so this warning was printing for many touch events. Now we print it only if the window that the platform plugin says *should* handle a touch move or release is non-null and *different* than the one that actually handled the press. Fixes: QTBUG-88192 Change-Id: Ia3271b5e67902dcf8a1cdae605adec470c3cfd89 Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
* Reset the velocity Kalman filter when the mouse enters a windowShawn Rutledge2020-11-101-0/+12
| | | | | | | | | | | | | | If we always tracked the mouse, we could always have accurate velocity; but most of the time, when the mouse enters a top-level window, we don't know how fast it was moving at that time, unless the application has requested a window-system mouse grab. It's better to assume that any residual velocity stored in the persistent QEventPoint instance (in QPointingDevicePrivate::activePoints) is inaccurate, and just start over from zero. Especially for the sake of autotest sanity. Task-number: QTBUG-88346 Change-Id: Id6c4fbffb8a86a8ab50a09f09aa62125d10155b4 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Remove code for non-enhanced mouse eventsShawn Rutledge2020-11-101-67/+25
| | | | | | | | | | | | Followup to a37785ec7638e7485112b87dd7e767881fecc114. The mouse button that caused the event and the current state of all mouse buttons must always be given separately in QPA mouse events. Task-number: QTBUG-59277 Task-number: QTBUG-62329 Task-number: QTBUG-63467 Change-Id: I27209b3730baef325ce0f1c4d3778930e72d5465 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* Fix mouse velocity calculationShawn Rutledge2020-11-061-1/+8
| | | | | | | | | | | | | The mouse event that is sent to QPlatformCursor is in native pixels, but the QSinglePointEvent constructor sets QEventPoint::globalLastPosition every time, and velocity is calculated by delta from globalLastPosition to globalPosition. We plan to rely on this velocity being correct in Qt Quick, in Flickable for example. So globalLastPosition and globalPosition need to be in the same coordinate system at the time QPointerEvent::setTimestamp() is called. Change-Id: I39f97a43f55f47a70cbd574861e920f3106e2125 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Another round of replacing 0 with nullptrAllan Sandfeld Jensen2020-10-071-1/+1
| | | | | | | | | This time based on grepping to also include documentation, tests and examples previously missed by the automatic tool. Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Ignore mouse events where globalPos contains NaNSteffen Kieß2020-10-021-0/+5
| | | | | | | | | | | | | | A NaN value in globalPos can cause an endless recursion in QGuiApplicationPrivate::processMouseEvent() when e->enhancedMouseEvent() is true and this is not a move event. When an event contains a NaN in globalPos, print a warning and ignore the event. Pick-to: 5.15 Fixes: QTBUG-86207 Change-Id: I8789e465921789569715e52c98193f91945ea982 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* End touch->mouse synthesis when the chosen touchpoint is releasedShawn Rutledge2020-10-021-27/+33
| | | | | | | | | | | | | | | | During delivery of a TouchBegin event, if no widget accepts it, we begin treating the first touchpoint as a synth-mouse, as before. If a second touchpoint is pressed or released in any order, it's irrelevant: the fake mouse button is released as soon as the first touchpoint is released. This fixes the bug that such a scenario caused the mouse release not to be sent, so that a widget could get "stuck" in pressed state. Done-with: Tang Haixiang <tanghaixiang@uniontech.com> Fixes: QTBUG-86253 Pick-to: 5.15 Change-Id: I7fbbe120539d8ded8ef5e7cf712a27bd69391e02 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Emit QScreen::geometryChanged when the logical DPI changesFriedemann Kleint2020-09-301-6/+5
| | | | | | | | | | | | | | | | | | | | Add the missing call to QScreenPrivate::emitGeometryChangeSignals() along with an emission of physicalDotsPerInchChanged() since that is calculated from geometry and physical size. Rearrange the code in QGuiApplicationPrivate::processScreenGeometryChange() to prevent duplicate emissions of geometryChanged(), physicalDotsPerInchChanged() which this change would introduce. Amends 5290027e3bab75f14fc0a2b7c206594d9cb91e76. Pick-to: 5.15 Task-number: QTBUG-76902 Task-number: QTBUG-79248 Fixes: QTBUG-86604 Change-Id: I3dc2ec5ccd9c6413e92f9246242f323e8afc5e57 Reviewed-by: David Edmundson <davidedmundson@kde.org>
* Use WAYLAND_DISPLAY and DISPLAY instead of XDG_SESSION_TYPEJohan Klokkhammer Helsing2020-09-271-18/+35
| | | | | | | | | | | | | | | | XDG_SESSION_TYPE is a non-standard part of systemd, and not set if you run a compositor from the command line, for instance. [ChangeLog][Wayland] XDG_SESSION_TYPE is no longer used to determine which platform plugin to use. Instead, if WAYLAND_DISPLAY is set in the environment, wayland is used. Similarly, if DISPLAY is set, xcb is used. If both are detected, wayland will be attempted first, then xcb. Gnome-shell is still skipped for automatic wayland detection. Fixes: QTBUG-75732 Change-Id: Ieed123330662dc29eafa31148a9b99ba0810de90 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Get rid of QMutableEventPoint::stationaryWithModifiedPropertyShawn Rutledge2020-09-251-6/+0
| | | | | | | | | | | | | | | | Omitting stationary points from touch events is such a marginal optimization that this code probably isn't worth maintaining. It wasn't implemented correctly this time either, according to the tst_QQuickMultiPointTouchArea::stationaryTouchWithChangingPressure() test. [ChangeLog][QtGui][QPointerEvent] We no longer attempt to avoid delivery of stationary points within QTouchEvent: every pressed point is now included in every TouchUpdate event. Task-number: QTBUG-77142 Change-Id: If1fd666fb3057a17e0dffdd7ca7138693126b02b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Mouse->touch synthesis: send touch event with mouse deviceShawn Rutledge2020-09-161-6/+1
| | | | | | | | | | | In 4e400369c08db251cd489fec1229398c224d02b4 we began to send synth-mouse events from the touch device, but in the opposite direction it was not consistent. Add autotests to prove that it's consistent both ways now. Change-Id: I7df2328fef224dc1529ca5d27411cd8a5a9c8df9 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Track grab state in QPointingDevicePrivate::activePointsShawn Rutledge2020-09-161-148/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QQuickEventPoint instances were very long-lived and got reused from one event to the next. That was initially done because they were "heavy" QObjects; but it also became useful to store state in them between events. But this is in conflict with the ubiquitous event replay code that assumes it's OK to hold an event instance (especially a QMouseEvent) for any length of time, and then send it to some widget, item or window. Clearly QEventPoints must be stored in the QPointerEvent, if we are to avoid the need for workarounds to keep such old code working. And now they have d-pointers, so copying is cheap. But replay code will need to detach() their QEventPoints now. QEventPoint is useful as an object to hold state, but we now store the truly persistent state separately in an EventPointData struct, in QPointingDevicePrivate::activePoints. Incoming events merely update the persistent points, then we deliver those instead. Thus when event handler code modifies state, it will be remembered even when the delivery is done and the QPA event is destroyed. This gets us a step closer to supporting multiple simultaneous mice. Within pointer events, the points are moved up to QPointerEvent itself: QList<QEventPoint> m_points; This means pointCount(), point(int i) and points() can be non-virtual. However in any QSinglePointEvent, the list only contains one point. We hope that pessimization is worthwhile for the sake of removing virtual functions, simplifying code in event classes themselves, and enabling the use of the range-for loop over points() with any kind of QPointerEvent, not just QTouchEvent. points() is a nicer API for the sake of range-for looping; but point() is more suited to being non-const. In QML it's expected to be OK to emit a signal with a QPointerEvent by value: that will involve copying the event. But QEventPoint instances are explicitly shared, so calling setAccepted() modifies the instance in activePoints (EventPointData.eventPoint.d->accept); and the grabbers are stored separately and thus preserved between events. In code such as MouseArea { onPressed: mouse.accepted = false } we can either continue to emit the QQuickMouseEvent wrapper or perhaps QEvent::setAccepted() could become virtual and set the eventpoint's accepted flag instead, so that it will survive after the event copy that QML sees is discarded. The grabChanged() signal is useful to keep QQuickWindow informed when items or handlers change exclusive or passive grabbers. When a release happens at a different location than the last move event, Qt synthesizes an additional move. But it would be "boring" if QEventPoint::lastXPosition() accessors in any released eventpoint always returned the same as the current QEventPoint::xPosition()s just because of that; and it would mean that the velocity() must always be zero on release, which would make it hard to use the final velocity to drive an animation. So now we expect the lastPositions to be different than current positions in a released eventpoint. De-inline some functions whose implementations might be subject to change later on. Improve documentation. Since we have an accessor for pressTimestamp(), we might as well add one for timestamp() too. That way users get enough information to calculate instantaneous velocity, since the plan is for velocity() to be somewhat smoothed. Change-Id: I2733d847139a1b1bea33c00275459dcd2a145ffc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Plumb application quit through platform pluginTor Arne Vestbø2020-09-141-0/+8
| | | | | | | | | | | | | | | | | | If we have a platform plugin we ask the platform to quit, and if not we fall back to the base implementation of QCoreApplication that sends Quit events directly. This allows the platform to involve the rest of the system in the process. The platform will then come back with a spontaneous quit via QWSI::handleApplicationTermination(), which will then send the corresponding Quit even from QGuiApplication like normal. Task-number: QTBUG-45262 Task-number: QTBUG-33235 Task-number: QTBUG-72013 Task-number: QTBUG-59782 Change-Id: I0000aaf7192e4b905933c5da0e53901c6c88f26a Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Get rid of hasPendingEvents() and flush()Lars Knoll2020-09-061-1/+0
| | | | | | | They are unused. Change-Id: I77383f2be45551401ed9c2f88285511134cc8b0d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Remove "fallback session management"Andreas Hartmetz2020-09-011-87/+1
| | | | | | | | | | | | | | With the Qt6 compatibility break, it can finally be removed. Closing windows (which might quit the application with quitOnLastWindowClosed() true, the default) acted contrary to the documentation of the commitDataRequest() signal, which could have been a hint. This removes the workaround API from the fix for QTBUG-49667 and also removes the problematic feature that it worked around. Change-Id: I672be58864ef062df7fb7f2a81658b92c4feedd2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* High-DPI: Remove usage of Qt::AA_EnableHighDpiScalingTor Arne Vestbø2020-08-281-1/+1
| | | | | | | | This attribute is now on by default. Change-Id: I7c9d2e3445d204d3450758673048d514bc9c850c Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* High-DPI: Don’t round scale factors in Qt 6Morten Johan Sørvig2020-08-281-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Set HighDpiScaleFactorRoundingPolicy to PassThough by default. This makes Qt track the system UI setting accurately, and is overall the least confusing option. Historically, Qt has rounded the scale factor (for example, Windows 175% -> DPR 2) due to faulty handling of fractional scale factors in Qt Widgets and with the native Windows style. Other areas of Qt such as Qt Quick have had few issues with fractional scale factors and support this well. Qt has never rounded the scale factor on the Android platform. Support for fractional scale factors in Qt Widgets and the windows style has improved, which makes changing the default for Qt 6 viable. Task-number: QTBUG-83068 Change-Id: I38b60f621f95be8ebb6cb84a07d3370fec19ab92 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Introduce QWindow::paintEvent with QPA plumbingTor Arne Vestbø2020-08-261-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The explicit paint event on QtGui and QPA level allows us to untangle the expose event, which today has at least 3 different meanings. It also allows us to follow the platform more closely in its semantics of when painting can happen. On some platforms a paint can come in before a window is exposed, e.g. to prepare the first frame. On others a paint can come in after a window has been de-exposed, to save a snapshot of the window for use in an application switcher or similar. The expose keeps its semantics of being a barrier signaling that the application can now render at will, for example in a threaded render loop. There are two compatibility code paths in this patch: 1. For platform plugins that do not yet report the PaintEvents capability, QtGui will synthesize paint events on the platform's behalf, based on the existing expose events coming from the platform. 2. For applications that do not yet implement paintEvent, QtGui will send expose events instead, ensuring the same behavior as before. For now none of the platform plugins deliver paint events natively, so the first compatibility code path is always active. Task-numnber: QTBUG-82676 Change-Id: I0fbe0d4cf451d6a1f07f5eab8d376a6c8a53ce8c Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Add note about use of receivedExpose member in QGuiApplicationTor Arne Vestbø2020-08-261-0/+6
| | | | | Change-Id: I221586a4fac394a9110d28905a898ab9688c1183 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Rename confusingly named QFont/QPalette::resolve overloadsVolker Hilsheimer2020-08-251-3/+3
| | | | | | | | | | | | | | | Having three methods with the same name doing different things is unnecessarily confusing, so follow the standard naming convention in Qt and call the getter of the resolve mask resolveMask, and the setter setResolveMask. These methods were all documented as internal. The publicly documented resolve() method that merges two fonts and palettes based on the respective masks remains as it is, even though 'merge' would perhaps be a better name. Change-Id: If90b1ad800834baccd1dbc38fc6b861540d6df6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QGuiApplication: fix handling of spontaneous events' modifiersNicolas Guichard2020-08-201-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | QtQuickTest synthetized events can have modifiers, but those modifiers were not accessible globally, from QGuiApplication::keyboardModifiers for instance. eg. calling QML's TestCase::mouseClick with modifiers triggering a call to QGuiApplication::keyboardModifiers did not give the expected result. QtTest synthesised events can also have modifiers and those were correctly handled by QApplication to set modifiers globally. This fix moves the handling code from QApplication::notify to QGuiApplicationPrivate::maybeSimulateModifiers and calls this function from QGuiApplication::notify too. The definite fix would be to do as suggested in the comment attached to the moved code: > Qt Test should not call qapp->notify(), but rather route the events > through the proper QPA interface. This is required to properly > generate all other events such as enter/leave etc. Pick-to: 5.15 5.12 Change-Id: I734e5bbc82232b13828b1a1f82e06ee8eb695417 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-25 02:13:35 +0000