summaryrefslogtreecommitdiffstats
path: root/src/widgets/kernel/qapplication.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Track grab state in QPointingDevicePrivate::activePointsShawn Rutledge2020-09-161-50/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Deliver Quit event when calling QCoreApplication::quit()Tor Arne Vestbø2020-09-071-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of QCoreApplication::quit() directly calling exit(0), which would leave QGuiApplication and client code out of the loop, we now send the Quit event, and let it pass through event delivery, before finally ending up in QCoreApplication::event(), where we call exit(0). This has the advantage that QGuiApplication can ensure all windows are closed before quitting, and if any of those windows ignore the close event the quit will be aborted. This aligns the behavior of synthetic quits via QCoreApplication::quit() with spontaneous quits from the platform via QGuiApplicationPrivate::processApplicationTermination. Clients who wish to exit the application without any event delivery or potential user interaction can call the lower level exit() function directly. [ChangeLog][QtGui] Application termination via qApp->quit() will now deliver Quit events to the application, which in turn will result in application windows being closed as part of the application quit, with an option to cancel the application quit by ignoring the close event. Clients who explicitly want to exit the application without any user interaction should call QCoreApplication::exit() explicitly. Task-number: QTBUG-45262 Task-number: QTBUG-33235 Task-number: QTBUG-72013 Task-number: QTBUG-59782 Change-Id: Id4b3907e329b9ecfd936fe9a5f8a70cb66b76bb7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> 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-7/+0
| | | | | | | | | | | | | | 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>
* macOS: rename 'macintosh' style to 'macos'Richard Moe Gustavsen2020-08-261-1/+1
| | | | | | | | | | | | | | Change the name/key of the style to 'macos'. Besides the name 'macintosh' being archaic, we also need this change to avoid creating 'macintosh' style folders in QtQuickControls, now that we plan to use QPlatformTheme also there to resolve the style. [ChangeLog][Widgets][QStyle] The 'macintosh' style has been renamed to 'macos'. Change-Id: I14b8a8b4dbd369e7a7d16b94e4ad27e501e7e8d0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Rename confusingly named QFont/QPalette::resolve overloadsVolker Hilsheimer2020-08-251-2/+2
| | | | | | | | | | | | | | | 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>
* Move QStateMachine from QtCore to QtScxmlKarsten Heimrich2020-08-241-13/+0
| | | | | | Task-number: QTBUG-80316 Change-Id: I2ee74110fd55e94d86321d3b3dc5bb8297424ed4 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
* QGuiApplication: fix handling of spontaneous events' modifiersNicolas Guichard2020-08-201-53/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Move QDesktopWidget API used by QApplication into QDesktopWidgetVolker Hilsheimer2020-08-171-2/+1
| | | | | | | | | | | QDesktopWidget is not a public class anymore and only exists for compatibility reasons. So we might just as well move the only method used by other classes out of QDesktopWidgetPrivate, and get rid of the friend declarations and the access-to-private code in QApplication. Change-Id: I74ff14233e59912e0930f98995f8af60dbadfdb6 Task-number: QTBUG-62094 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Ensure styles always get to polish the application paletteTor Arne Vestbø2020-07-211-17/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before 0a93db4d82c051164923a10e4382b12de9049b45 we would polish the application palette even when it was the default palette, as we always recreated the system palette each time a style was set. After the change we skipped polishing the palette unless it was set by the user, under the assumption that the style would set its own default palette if it wanted to override the system palette. This turned out to break the style's ability to slightly tweak the palette via polish (versus the more full on standardPalette approach). We now polish both the default palette and user palettes, and we do so as part of the normal palette update logic. This ensures that the style also gets a chance to polish the palette when the platform theme changes. The polish will not have an effect on the resolve mask of the palette, as the polish is conceptually the same as a base palette, and should not affect e.g. Qt::AA_SetPalette. Fixes: QTBUG-85469 Fixes: QTBUG-85188 Pick-to: 5.15 Change-Id: I869e9c442b177de4f1dc49eb75220709306f4d12 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QtGui: Rename all QEvent members according to the m_ conventionFriedemann Kleint2020-07-161-4/+6
| | | | | | | | | | | As they are protected, they need to be excluded from the Python bindings, which is best done by a pattern. Task-number: PYSIDE-1339 Task-number: PYSIDE-904 Change-Id: I667aa3b8e229e11b3b46635adfddbd62ce4747c1 Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Change QWindow/QWidget::map(To/From)(Global/Parent) to operate in floatFriedemann Kleint2020-07-141-6/+3
| | | | | | | | | | | | | | | Change the functions to operate in float and add the QPoint versions as overload calling them. This is more in-line with the event accessors using float and allows for removing some workarounds using a delta when converting touch points. Leave QPlatformWindow::map(To/From)Global() as is for now and add helpers for float. Change-Id: I2d46b8dbda8adff26539e358074b55073dc80b6f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Refactor pointer event hierarchyShawn Rutledge2020-07-101-45/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some goals that have hopefully been achieved are: - make QPointerEvent and QEventPoint resemble their Qt Quick counterparts to such an extent that we can remove those wrappers and go back to delivering the original events in Qt Quick - make QEventPoint much smaller than QTouchEvent::TouchPoint, with no pimpl - remove most public setters - reduce the usage of complex constructors that take many arguments - don't repeat ourselves: move accessors and storage upwards rather than having redundant ones in subclasses - standardize the set of accessors in QPointerEvent - maintain source compatibility as much as possible: do not require modifying event-handling code in any QWidget subclass To avoid public setters we now introduce a few QMutable* subclasses. This is a bit like the Builder pattern except that it doesn't involve constructing a separate disposable object: the main event type can be cast to the mutable type at any time to enable modifications, iff the code is linked with gui-private. Therefore event classes can have less-"complete" constructors, because internal Qt code can use setters the same way it could use the ones in QTouchEvent before; and the event classes don't need many friends. Even some read-accessors can be kept private unless we are sure we want to expose them. Task-number: QTBUG-46266 Fixes: QTBUG-72173 Change-Id: I740e4e40165b7bc41223d38b200bbc2b403e07b6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix delivery of MouseMove events to newly opened popup windowsVolker Hilsheimer2020-07-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Amend d934fd7f54eae24ea3f719890e2c4dbbc445049d, which was too naive in assuming that any change to the popup stack while a popup had been pressed into should result in mouse move events to be delivered without buttons. Instead, add a new flag that is set explicitly when the qt_popup_down widget is closed, and remove buttons from the move move events only when that flag is set. Add the sorely missing test case as well, even if we have to accept that not all behavior can be tested reliably. Ie. on macOS, the simulated mouse event differs from the event we do get from the QPA plugin or the system; on Xcb, some of the behavior depends on the window manager. This is something we could try to clean up for Qt 6. Change-Id: Ibf0a0a6fb7d401915057365788947e5a35aa20c3 Fixes: QTBUG-84926 Task-number: QTBUG-82538 Pick-to: 5.15 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Liang Qi <liang.qi@qt.io>
* Skip proxy widgets that can't take focus when (back)tabbingVolker Hilsheimer2020-06-251-4/+6
| | | | | | | | | | | | | | Fixes regression introduced in b4981f9d4ca914c6ecaa49bfdd69e51806a3671a, due to which it was possible to back-tab into a widget even though it or its focusProxy had a NoFocus policy. As a drive-by, split the complicated if-statement up a bit for improved readability. Change-Id: Ib0ac2604076e812e340b11534c23ae8ae958d082 Fixes: QTBUG-76924 Pick-to: 5.15 5.12 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Introduce QInputDevice hierarchy; replace QTouchDeviceShawn Rutledge2020-06-161-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have seen during the Qt 5 series that QMouseEvent::source() does not provide enough information: if it is synthesized, it could have come from any device for which mouse events are synthesized, not only from a touchscreen. By providing in every QInputEvent as complete information about the actual source device as possible, we will enable very fine-tuned behavior in the object that handles each event. Further, we would like to support multiple keyboards, pointing devices, and named groups of devices that are known as "seats" in Wayland. In Qt 5, QPA plugins registered each touchscreen as it was discovered. Now we extend this pattern to all input devices. This new requirement can be implemented gradually; for now, if a QTWSI input event is received wtihout a device pointer, a default "core" device will be created on-the-fly, and a warning emitted. In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when multiple devices were in use simultaneously. Now that each event identifies the device it came from, this hack is no longer needed. A stub of the new QPointerEvent is added; it will be developed further in subsequent patches. [ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer to an instance of QInputDevice, or the subclass QPointingDevice in case of mouse, touch and tablet events. Each platform plugin is expected to create the device instances, register them, and provide valid pointers with all input events. If this is not done, warnings are emitted and default devices are created as necessary. When the device has accurate information, it provides the opportunity to fine-tune behavior depending on device type and capabilities: for example if a QMouseEvent is synthesized from a touchscreen, the recipient can see which touchscreen it came from. Each device also has a seatName to distinguish users on multi-user windowing systems. Touchpoint IDs are no longer unique on their own, but the combination of ID and device is. Fixes: QTBUG-46412 Fixes: QTBUG-72167 Task-number: QTBUG-69433 Task-number: QTBUG-52430 Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Phase 2 of removing QDesktopWidgetVolker Hilsheimer2020-06-081-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Remove QDestopWidget public header, simplify the implementation that maintains a Qt::Desktop type QWidget for each QScreen, and turn QWidget's initial target screen into a QScreen pointer. QApplication::desktop() now takes an optional QScreen pointer, and returns a QWidget pointer, so that applications and widgets can get access to the root widget for a specific screen without having to resort to private APIs. QDesktopWidgetPrivate implementations to look up a screen for an index, widget, or point are now all inline functions that thinly wrap QGuiApplication::screens/screenAt calls. We should consider adding those as convenience APIs to QScreen instead. Note that QWidget::screen is assumed to return a valid pointer; there is code that handles the case that it returns nullptr (but also code that trusts that it never is nullptr), so this needs to be defined, verified with tests, and asserted. We can then simplify the code further. Change-Id: Ifc89be65a0dce265b6729feaf54121c35137cb94 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Replace calls to deprecated QEvent accessor functionsShawn Rutledge2020-06-081-24/+24
| | | | | | | Many of these were generated by clazy using the new qevent-accessors check. Change-Id: Ie17af17f50fdc9f47d7859d267c14568cc350fd0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix build without features.actionTasuku Suzuki2020-06-041-0/+2
| | | | | Change-Id: Ie37036e44da9b552dc7e46ce94db7b50ce2f8a0b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Reduce QDesktopWidget API to bare minimumVolker Hilsheimer2020-05-151-0/+2
| | | | | | | | | | | | | | | | | The class is documented as obsolete, and the majority of APIs is marked as deprecated. In this first phase, remove all explicitly deprecated APIs and trivial implementations. The test case is complete removed; what's left when code that uses any of those deprecated methods is removed is not testing anything meaningful. For some methods, there is no practical replacement using QScreen yet, and QDesktopWidget is still used in QWidget internals. Those require refactoring to only use QScreen before the rest can be removed. Change-Id: I8f7c968ec566820077221d37b817843758d51d49 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Deprecate QGuiApplication::paletteChanged() signalAndy Shaw2020-05-151-6/+4
| | | | | | | | | | | | | | Rather than have a paletteChanged() signal which can be connected to for tracking when the application palette has changed, then it is better to use the event that is sent to all windows and the application itself. That way it is easy for a window/widget or item that cares about the change to the application font to catch it in the event() function. [ChangeLog][QtGui][QGuiApplication] Deprecated paletteChanged() signal in favor of QEvent::ApplicationPaletteChanged. Change-Id: I95da211e30590e357007cc14d8ee266baceba7b3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QApplication: refactor delivery and propagation of wheel eventsVolker Hilsheimer2020-05-131-59/+55
| | | | | | | | | | | | | | | | | | | | | | | | Handle wheel grabbing via wheel_widget in a single place, and propagate events in the same way for all (spontaneous) events. Handle ScrollMomentum the same way as ScrollUpdate to allow partial sequences. Fix the incorrect ignoring of wheel events by default; like all other input events, they are now again accepted by default and ignored in the default event handler implementation of QWidget. This way, implementing the handle suffices to accept the event. Note that QWidget::wheelEvent doesn't need to be changed, as the event is ignored there today (an oversight of the change made in f253f4c3, perhaps). This also fixes changing of direction of a wheel event while the event sequence is grabbed by a widget. Change-Id: Ia0f03c14dede80322d690ca50d085898a0497dbe Fixes: QTBUG-67032 Task-number: QTBUG-79102 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove obsolete storage, constructors and accessors in QEvent subclassesShawn Rutledge2020-05-121-16/+0
| | | | | Change-Id: I5c51244031ff40f1972106ad4fe27010c8be1193 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QApplication: deliver all wheel events to widget that accepts the firstVolker Hilsheimer2020-04-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For kinetic wheel events, Qt tries to make sure that all events in the stream go to the widget that accepted the first wheel event. It did so by directing all events from the stream to the widget from which the spontaneous event was returned as accepted. However, that widget might have passed the event on to some other widgets; e.g QScrollArea forwards wheel events from the viewport to the relevant scroll bar. The event might then have come back accepted only because parent propagation kicked in (the scrollbar might not accept the event, so the parents get a chance, and some parent's scrollbar ultimately accepts the event). In this scenario, the wheel widget would be the viewport under the mouse, when it should have been the scrollbar of the parent. The next events from the stream were then delivered to a widget that didn't scroll; and parent propagation is not (and should not be) implemented for the case where Qt has a wheel widget. Instead, make the first widget that accepts any initial wheel event the wheel widget, even if the event was not spontaneous. With this change, all events from the stream are delivered to the widget that actually handled the event. That has the effect that ie. a viewport of a scroll area only gets the first event; all following events are delivered directly to the scrollbar. The test case added simulates the different scenarios - nesting of scroll areas, classic wheel events and a stream of kinetic wheel events. [ChangeLog][QtWidgets][QApplication] Wheel events from a device that creates an event stream are correctly delivered to the widget that accepts the first wheel event in the stream. Change-Id: I5ebfc7789b5c32ebc8d881686f450fa05ec92cfe Fixes: QTBUG-79102 Pick-to: 5.15 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Deprecate QGuiApplication::fontChanged() signalAndy Shaw2020-04-241-10/+4
| | | | | | | | | | | | | | Rather than have a fontChanged() signal which can be connected to for tracking when the application font has changed, then it is better to use the event that is sent to all windows and the application itself. That way it is easy for a window/widget or item that cares about the change to the application font to catch it in the event() function. [ChangeLog][QtGui][QGuiApplication] Deprecated fontChanged() signal in favor of QEvent::ApplicationFontChanged. Change-Id: Iae8e832238fc85e385a52305bc04f16e597454b0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Port QT_NO_TOOLTIP to QT_CONFIG(tooltip)Joerg Bornemann2020-04-211-2/+4
| | | | | | | | | | | | We remove the QT_NO_TOOLTIP check from qstandarditemmodel.h, because as the 'tooltip' feature is in QtWidgets, we cannot use it properly in QtGui. Also this affects just two non-virtual inline methods, i.e. it has no effect on library size. Task-number: QTBUG-82785 Change-Id: Ic166f14fb1cf3e9dd789573a6b9db6a87fb50e10 Reviewed-by: Tasuku Suzuki <tasuku.suzuki@kdab.com> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-04-111-1/+1
|\ | | | | | | | | | | | | Conflicts: tests/auto/network/socket/platformsocketengine/platformsocketengine.pri Change-Id: I22daf269a8f28f80630b5f521b91637531156404
| * Remove more calls to deprecated TouchPoint functionsShawn Rutledge2020-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Followup to ed3ed0b9db97a8fab0c03add23228b6b0a96f171 68916fede41d1eca5d07eb6b1db518d41a007616 and 3c159957f863cf8d367a9261e7016e52cd0348c1. In QWindowSystemInterfacePrivate::fromNativeTouchPoints() and QWindowSystemInterfacePrivate::toNativeTouchPoints() we continue using struct TouchPoint's QRectF area as storage for the screen position + ellipse diameters; as the comment says, this is _unrotated_, meaning that rotation is stored separately, and area should not be construed as the bounding box of the rotated ellipse. (In Qt 6 we can make the QPA touchpoint look the same as the QTouchEvent::TouchPoint to eliminate the need to calculate the center of the rect.) In QGraphicsScenePrivate::updateTouchPointsForItem(), setRect() sets the position and the ellipse diameters, but the latter is redundant because the purpose of this function is to localize a touchpoint to the coordinate system of a particular QGraphicsItem. Ellipse diameters should stay the same. In QApplicationPrivate::updateTouchPointsForWidget(), as in QGraphicsScene, we are localizing touchpoints to a widget and to the screen that the widget is shown on, so only the position needs to be set, while preserving the sub-pixel resolution that mapFromGlobal(QPoint) loses. Fixes: QTBUG-83403 Change-Id: I61d29e14cbe38567767b164af6ae895082c5e1a1 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | QApplication: remove obsolete globalStrut functionalityVolker Hilsheimer2020-04-101-28/+0
| | | | | | | | | | | | Change-Id: If56873f86f5291264cac720f8db7dbd4db756f49 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | QApplication: remove obsolete keypadNavigationEnabled memberVolker Hilsheimer2020-04-091-46/+1
| | | | | | | | | | | | | | | | QApplicationPrivate::keypadNavigationEnabled remains, and is used in many places in QtWidgets. Change-Id: Id95239560c279850f340f65414acb92202d10367 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* | Merge "Merge remote-tracking branch 'origin/5.15' into dev"Qt Forward Merge Bot2020-04-081-1/+1
|\ \
| * | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-04-081-1/+1
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/opengl/doc/src/cube.qdoc src/corelib/global/qlibraryinfo.cpp src/corelib/text/qbytearray_p.h src/corelib/text/qlocale_data_p.h src/corelib/time/qhijricalendar_data_p.h src/corelib/time/qjalalicalendar_data_p.h src/corelib/time/qromancalendar_data_p.h src/network/ssl/qsslcertificate.h src/widgets/doc/src/graphicsview.qdoc src/widgets/widgets/qcombobox.cpp src/widgets/widgets/qcombobox.h tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp tests/benchmarks/corelib/io/qdiriterator/qdiriterator.pro tests/manual/diaglib/debugproxystyle.cpp tests/manual/diaglib/qwidgetdump.cpp tests/manual/diaglib/qwindowdump.cpp tests/manual/diaglib/textdump.cpp util/locale_database/cldr2qlocalexml.py util/locale_database/qlocalexml.py util/locale_database/qlocalexml2cpp.py Resolution of util/locale_database/ are based on: https://codereview.qt-project.org/c/qt/qtbase/+/294250 and src/corelib/{text,time}/*_data_p.h were then regenerated by running those scripts. Updated CMakeLists.txt in each of tests/auto/corelib/serialization/qcborstreamreader/ tests/auto/corelib/serialization/qcborvalue/ tests/auto/gui/kernel/ and generated new ones in each of tests/auto/gui/kernel/qaddpostroutine/ tests/auto/gui/kernel/qhighdpiscaling/ tests/libfuzzer/corelib/text/qregularexpression/optimize/ tests/libfuzzer/gui/painting/qcolorspace/fromiccprofile/ tests/libfuzzer/gui/text/qtextdocument/sethtml/ tests/libfuzzer/gui/text/qtextdocument/setmarkdown/ tests/libfuzzer/gui/text/qtextlayout/beginlayout/ by running util/cmake/pro2cmake.py on their changed .pro files. Changed target name in tests/auto/gui/kernel/qaction/qaction.pro tests/auto/gui/kernel/qaction/qactiongroup.pro tests/auto/gui/kernel/qshortcut/qshortcut.pro to ensure unique target names for CMake Changed tst_QComboBox::currentIndex to not test the currentIndexChanged(QString), as that one does not exist in Qt 6 anymore. Change-Id: I9a85705484855ae1dc874a81f49d27a50b0dcff7
| | * macOS: Remove all use of deprecated Q_OS_OSX defineTor Arne Vestbø2020-04-031-1/+1
| | | | | | | | | | | | | | | Change-Id: I49c285604694c93d37c9d1c7cd6d3b1509858319 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | | Remove global GDI helpers qt_win_display_dc and qt_region_from_HRGNVolker Hilsheimer2020-04-081-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | They were no longer used anyway. Change-Id: I565480cf39d2d8a27735afe56ac6537bc62fbd4a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | | QApplication: remove forwarding of QGuiApplication::windowIconVolker Hilsheimer2020-04-081-18/+0
| | | | | | | | | | | | | | | Change-Id: If886b0187bd5a6e0d57f6f0ed6bc4fca3edbe435 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | | QApplication: remove deprecated members for obsolete ColorSpecVolker Hilsheimer2020-04-081-93/+0
|/ / | | | | | | | | Change-Id: Idf1f4fd34e22c0ecac50a030e709d90b46dd6145 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* / Remove QGuiAction again and split QAction implementation up insteadVolker Hilsheimer2020-03-291-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | Duplicating the number of classes is a high price to pay to be able to have some QAction functionality behave differently, or be only available in widgets applications. Instead, declare the entire API in QtGui in QAction* classes, and delegate the implementation of QtWidgets specific functionality to the private. The creation of the private is then delegated to the Q(Gui)ApplicationPrivate instance through a virtual factory function. Change some public APIs that are primarily useful for specialized tools such as Designer to operate on QObject* rather than QWidget*. APIs that depend on QtWidgets types have been turned into inline template functions, so that they are instantiated only at the caller side, where we can expect the respective types to be fully defined. This way, we only need to forward declare a few classes in the header, and don't need to generate any additional code for e.g. language bindings. Change-Id: Id0b27f9187652ec531a2e8b1b9837e82dc81625c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix docs suggesting that it's possible to draw to the X11 screenSimon Hausmann2020-03-171-2/+0
| | | | | | | | | It's not possible anymore, since many years. The desktop's don't use the X11 root window anymore :) Fixes: QTBUG-82880 Change-Id: I923f29f23e61d93640cacb2ac20620c5ddc480b9 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Send the LanguageChange event to all top level windows, not just widgetsAndy Shaw2020-02-181-1/+4
| | | | | | | | | | | By sending it to all top level windows it will make it possible for non widget based controls to listen for this event if it cares about it so it can handle translation updates as appropriate. Task-number: QTBUG-78141 Task-number: QTBUG-82020 Change-Id: I8f35cdcccd81a199ff780c3f4f3d2c663480d638 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Deprecate QTabletEvent::device() in favor of deviceType()Shawn Rutledge2020-02-171-1/+1
| | | | | | | | | The idea is to reserve device() to return a pointer to a QInputDevice in the future, which is in sync with QQuickPointerEvent::device() and with QTouchEvent::device(). Change-Id: Ifda6e8aea72d5121955b31bdcbd91bf1bfa4cec4 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-01-281-1/+2
|\ | | | | | | | | | | | | Conflicts: src/gui/image/qpnghandler.cpp Change-Id: I8630f363457bb613d8fb88470a71d95d97cdb301
| * Make sure the focus is passed on correctly when back-tabbingAndy Shaw2020-01-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | When the tested widget has a focus proxy, then we should check if the current focus widget is not the same as that focus proxy before setting it to be the widget that gets focus. This ensures that when back-tabbing from a widget like QDoubleSpinBox that it will not get stuck inside that widget and will back-tab to the next correct one. Fixes: QTBUG-81097 Change-Id: I3f689c7715da7f3ce8c3d2f616041528f5778a2f Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | QMenu: don't crash when another popup is closed when a popup is closedChristian Ehrlicher2020-01-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | When closing a popup (submenu) triggers closing another popup (the menu) programatically it can happen that QApplicationPrivate::popupWidgets is destroyed. Therefore we have to check if popupWidgets is still valid after the focus change event was delivered. Fixes: QTBUG-81222 Change-Id: Ide3a6897e43f389d396a80d8b158f7c8eb04e3aa Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Mark QApplication::globalStrut as deprecatedVolker Hilsheimer2020-01-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This property is obsolete with today's user interface reality, and was never consistently implemented in all styles and widgets. Deprecating it for Qt 5.15 as preparating for removing the code for Qt 6. [ChangeLog][QtWidgets][QApplication] The globalStrut property has been deprecated and will be removed from Qt 6 Change-Id: Iaea88e563144481a395de6cf0745a512e386407d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Unify application palette handling between QGuiApplication and QApplicationTor Arne Vestbø2020-01-131-134/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic is now mostly handled in QGuiApplication, with QApplication only dealing with the widget-specific palettes and interaction between the style and the palette. The application now picks up changes to the platform theme and will re-resolve the current application palette appropriately. This also works even if an explicit application palette has been set, in which case any missing roles are filled in by the theme. The palette can now also be reset back to the default application palette that's fully based on the theme, by passing in the default constructed palette (or any palette that doesn't have any roles set). This is also correctly reflected in the Qt::AA_SetPalette attribute. Conceptually this means QGuiApplication and QApplication follow the same behavior as QWidget, where the palette falls back to a base or inherited palette for roles that are not set, in this case the theme. Behavior-wise this means that the default application palette of the application does not have any roles set, but clients should not have relied on this, nor does QWidget rely on that internally. It also means that setting a palette on the application and then getting it back again will not produce the same palette as set, since the palette was resolved against the theme in the meantime. This is the same behavior as for QWidget, and although it's a behavior change it's one towards a more sane behavior, so we accept it. [ChangeLog] Application palettes are now resolved against the platform's theme palette, the same way widget palettes are resolved against their parents, and the application palette. This means the application palette reflected through QGuiApplication::palette() may not be exactly the same palette as set via QGuiApplication::setPalette(). Change-Id: I76b99fcd27285e564899548349aa2a5713e5965d Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Liang Qi2020-01-091-31/+24
|\| | | | | | | | | | | | | Conflicts: src/corelib/kernel/qobject.cpp Change-Id: I4780b25665672692b086ee92092e506c814642f2
| * Remove clearWidgetPaletteHash argument from setPalette_helperTor Arne Vestbø2020-01-091-5/+4
| | | | | | | | | | | | | | | | | | | | The argument is only used when the application palette is set, (as opposed to setting the palette for a specific widget class), and that code path is only triggered from QApplication::setPalette, which passes 'true' for this argument. Change-Id: I67a1cc3741f6f62653b0f95ff88d28228f9977d4 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Move tracking of widget specific app palettes to QApplicationPrivateTor Arne Vestbø2020-01-091-22/+20
| | | | | | | | | | Change-Id: I43cc25207026f174e46534baedf08e0c300728d1 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Share updates to QGuiApplicationPrivate::app_pal via helper functionTor Arne Vestbø2020-01-091-5/+1
| | | | | | | | | | Change-Id: I2f582358efaadcd33b39c52317222322c589423f Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-01-091-1/+1
|\| | | | | | | Change-Id: I9b4816b4aa6f0c51a446742db58b9d0dcf69aa09
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 11:17:28 +0000