summaryrefslogtreecommitdiffstats
path: root/src/widgets/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Widgets: Use effect region bounds when drawing with repaint managerAntti Määttä2022-05-173-3/+6
| | | | | | | | | | | | When drawing widgets with graphics effect using repaint manager, if we do not combine the effect region some child widgets are not affected by the graphics effect since they are not included in the dirty region. However always using region bounds breaks the referenced bug use case. Fixes: QTBUG-102374 Pick-to: 6.3 6.2 5.15 Change-Id: Iaf4eaba34db863500a0600b344e5062f2b36b9bf Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-1659-2243/+119
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Remove ALIEN_DEBUG statementsDavid Skoland2022-05-032-34/+1
| | | | | | | | These debug statements come from the Nokia import and it seems unlikely that they are being used at all. Change-Id: I3143f83b0acdc5130fb743808003a55b789f2398 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QtWidgets: use _L1 for for creating Latin-1 string literalsSona Kurazyan2022-05-025-12/+21
| | | | | | Task-number: QTBUG-98434 Change-Id: I310ea8f19d73a79d985ebfb8bfbff7a02c424360 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QtWidgets: includemocs v2022Marc Mutz2022-04-292-1/+2
| | | | | | | | | | | | | | | This makes mocs_compilation.cpp empty again, removing those moc files that were added after the last sweep in 2016, 0e6ad275498dc8cc60a7d163bac9ed0add8e48d5. Including moc files directly into their classes' TU tends to improve codegen and enables extended compiler warnings, e.g. about unused private functions or fields. Pick-to: 6.3 6.2 5.15 Task-number: QTBUG-102886 Change-Id: Iee35e82d18690469ad889f9b4a7394e706fe037d Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QGraphicsScene: Fix popup position for QGraphicsProxyWidgetVolodymyr Zibarov2022-04-221-25/+14
| | | | | | | | | | | | | screenGeometry() for proxy widget was returning visible part of the scene instead of screen geometry for enclosing first view Pass button center position to screenGeometry() to get correct screen for cases when graphics view occupies two screens Fixes: QTBUG-98785 Pick-to: 6.2 6.3 Change-Id: Idaeb3c3faf739751c93624a06fa0fd3d65388236 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Rename QGuiApplicationPrivate::notifyThemeChanged to handleThemeChangedTor Arne Vestbø2022-04-212-3/+3
| | | | | | | | The work done by QGuiApplicationPrivate in response to a theme change goes beyond notifying. Change-Id: I27c74adf6549c553e659c7b8e271945ce753031c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QApplication: deliver activation events for non-widget windowsRichard Moe Gustavsen2022-04-211-1/+14
| | | | | | | | | | | | | | | | | | Problem: if you create a hybrid Widgets and Quick Controls application, you would need to use QApplication rather than QGuiApplication. But in that case, the QQuickWindows would never receive window activation events from QApplication. And this causes problems for controls, since, for example, the palettes in use there will never update upon activation changes, and instead sometimes get stuck as e.g QPalette::Inactive after application startup. This patch will make sure that we send out activation events also for QWindows that are not QWidgetWindows. Pick-to: 6.3 6.2 Change-Id: I649f5c653081c0c5249f4faf28a7de2c92f17421 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Rest of QtBase: sweep Q_DECLARE_METATYPE → QT_DECL_METATYPE_EXTERNMarc Mutz2022-04-072-4/+16
| | | | | | | | | | | | | | | | It's one of our best tools to improve compile times. In some places, we can't do the change, yet, because there's no .cpp file for the header file. Also mark Q_DECLARE_METATYPE macros that are in the wrong place. We shouldn't have Q_D_M markup for public classes in .cpp or _p.h files. Fixes: QTBUG-102206 Change-Id: Iec0a39e4745571b24d07dacc87593321967c10e3 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Query the QWindow in every test iteration in qWFWExposed(QWidget)Laszlo Agocs2022-03-291-6/+29
| | | | | | Task-number: QTBUG-102030 Change-Id: Ic8aee76570a000709b480ffbe19335518e3f7a7e Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Notify about focus object changes upon widget destructionVolker Hilsheimer2022-03-251-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | If the active QWidget gets destroyed, then QWidgetWindow::focusObject will return nullptr. If then no other object takes focus, then we'd never emit change signals, and QGuiApplication's _q_updateFocusObject (which then informs the input context and emits signals) didn't get called. This left the input context with a dangling focus object pointer, which resulted in crashes. If the QWidget clears its focus, but the corresponding window doesn't know that it had focus, then fall back to the widget's focus widget to see if we have a change in focus, so that signals get emitted. Add a test case that shows that we didn't call _q_updateFocusObject by counting emissions of the QGuiApplication::focusObjectChanged signal, which we emit in this function. The signal is emitted more than once both when showing a widget, and now also when destroying a widget that has a focus child. The former is a previous issue, the latter is an improvement to not emitting the signal at all. Pick-to: 6.3 6.2 Fixes: QTBUG-101423 Fixes: QTBUG-101321 Change-Id: Ib96a397211d442f52ce795a3eebd055a0ef51b0d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Remove a now-unneeded QT_NO_OPENGL ifdefLaszlo Agocs2022-03-201-2/+0
| | | | | | | | | | | | This is from a fix unrelated to the recent rhi-based composition work, which means it still had to enclose the block in an ifdef due to the variables being only present in OpenGL-enabled builds. Now with the other patches in place, the variables are no longer conditional, and the similar ifndef QT_NO_OPENGL checks are already gone pretty much everywhere so the ifdef is not needed here either. Change-Id: I497c7a4fad7cd7d8fc1a479e7032de3e2cbb3b32 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* QObject: restore flags printing in dumpObjectTree()Marc Mutz2022-03-192-0/+23
| | | | | | | | | | | | | | | | | | | | This was lost when QtCore, QtGui and QtWidgets were split up. Restored now via a virtual function on QObjectPrivate. Chose to return std::string instead of QString or QByteArray because its SSO is usually sufficient to hold these flag strings. [ChangeLog][QtCore][QObject] Restored printing of Qt3-style information from dumpObjectTree(). [ChangeLog][QtWidgets][QWidget] Restored printing of Qt3-style information from QWidget::dumpObjectTree(). Fixes: QTBUG-101732 Change-Id: I39ff5728ea5f5abbdbf81b5d7e13b8d16b6ee8b7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Widgets: Do not depend on transitive includesFabian Kosmale2022-03-172-0/+2
| | | | | Change-Id: Idfd7af066264dd38375d45771693a536a1985607 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QFormLayout: Fix assert when showing with hidden rowsVolker Hilsheimer2022-03-151-14/+14
| | | | | | | | | | | | | | | | | | Amends a74cdf778c0c72fa22d9354207d729b2cbf88128, after which the initialization of items in invisible rows is skipped. Since data members in QFormLayoutItem were lazily initialized, this resulted in out-of-bounds access of QList entries. Use member initialization for all QFormLayoutItem fields, and check that vLayoutIndex is valid before using it to access the list entry. Skip labels and fields for which it is not initialized. Add test case. As a drive-by, silence the test's provoked warning messages via ignoreMessage. Change-Id: I374b414a51df20b9af3087a2676061fc6b7f23e2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Restore C++20-deprecated mixed-enum bitwise operatorsMarc Mutz2022-03-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C++20 deprecated arithmetic on enum types. For enums used on QFlags<>, these operators have always been user-defined, but when the two enums are of different type, such as QFrame::Shape and QFrame::Shadow, the deprecation warning pops up. We have in the past fixed these in our headers by manual casts, but that doesn't help our users when our API requires them to OR together enums of different type. Until we can rework these APIs to use a variadic QFlags type, we need to fix it in an SC and BC way, which is what this patch sets out to do. The idea is simply to mark pairs of enums that are designed to be ORed together and replace the deprecated built-in bitwise operators with user-defined ones in C++20. To ensure SC and BC, we pass an explicit result type and use that to check, in C++17 builds, that it matches the decltype of the result of the built-in operator. This patch is the first in a series of similar patches. It introduces said markup macro and applies it to all enum pairs that create warnings on (my) Linux GCC 11.3 and Clang 10.0.0 builds. It is expected that more such markups are needed, for other modules, and for symmetry. Even with this patch, there is one mixed-enum warning left, in qxcbwindow.cpp. This appears to be a genuine bug (cf. QTBUG-101306), so this patch doesn't mark the enums involved in it as designed to be used together. This patch also unearthed that QT_TYPESAFE_FLAGS, possibly unsurprisingly so, breaks several mixed bitwise flags-enum operations (QTBUG-101344). Pick-to: 6.3 6.2 5.15 Task-number: QTBUG-99948 Change-Id: I86ec11c1e4d31dfa81e2c3aad031b2aa113503eb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Fix losing QOpenGLWidget paints when a child widget is invisibleLaszlo Agocs2022-03-141-0/+7
| | | | | | | | Pick-to: 6.3 6.2 Change-Id: I136b486d30e31acadd6b1b837dc7e834ee3e23fb Fixes: QTBUG-101620 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Compose render-to-texture widgets through QRhiLaszlo Agocs2022-03-116-176/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QPlatformTextureList holds a QRhiTexture instead of GLuint. A QPlatformBackingStore now optionally can own a QRhi and a QRhiSwapChain for the associated window. Non-GL rendering must use this QRhi everywhere, whereas GL (QOpenGLWidget) can choose to still rely on resource sharing between contexts. A widget tells that it wants QRhi and the desired configuration in a new virtual function in QWidgetPrivate returning a QPlatformBackingStoreRhiConfig. This is evaluated (among a top-level's all children) upon create() before creating the repaint manager and the QWidgetWindow. In QOpenGLWidget what do request is obvious: it will request an OpenGL-based QRhi. QQuickWidget (or a potential future QRhiWidget) will be more interesting: it needs to honor the standard Qt Quick env.vars. and QQuickWindow APIs (or, in whatever way the user configured the QRhiWidget), and so will set up the config struct accordingly. In addition, the rhiconfig and surface type is (re)evaluated when (re)parenting a widget to a new tlw. If needed, this will now trigger a destroy - create on the tlw. This should be be safe to do in setParent. When multiple child widgets report an enabled rhiconfig, the first one (the first child encountered) wins. So e.g. attempting to have a QOpenGLWidget and a Vulkan-based QQuickWidget in the same top-level window will fail one of the widgets (it likely won't render). RasterGLSurface is no longer used by widgets. Rather, the appropriate surface type is chosen. The rhi support in the backingstore is usable without widgets as well. To make rhiFlush() functional, one needs to call setRhiConfig() after creating the QBackingStore. (like QWidget does to top-level windows) Most of the QT_NO_OPENGL ifdefs are eliminated all over the place. Everything with QRhi is unconditional code at compile time, except the actual initialization. Having to plumb the widget tlw's shareContext (or, now, the QRhi) through QWindowPrivate is no longer needed. The old approach does not scale: to implement composeAndFlush (now rhiFlush) we need more than just a QRhi object, and this way we no longer pollute everything starting from the widget level (QWidget's topextra -> QWidgetWindow -> QWindowPrivate) just to send data around. The BackingStoreOpenGLSupport interface and the QtGui - QtOpenGL split is all gone. Instead, there is a QBackingStoreDefaultCompositor in QtGui which is what the default implementations of composeAndFlush and toTexture call. (overriding composeAndFlush and co. f.ex. in eglfs should continue working mostly as-is, apart from adapting to the texture list changes and getting the native OpenGL texture id out of the QRhiTexture) As QQuickWidget is way too complicated to just port as-is, an rhi manual test (rhiwidget) is introduced as a first step, in ordewr to exercise a simple, custom render-to-texture widget that does something using a (not necessarily OpenGL-backed) QRhi and acts as fully functional QWidget (modeled after QOpenGLWidget). This can also form the foundation of a potential future QRhiWidget. It is also possible to force the QRhi-based flushing always, regardless of the presence of render-to-texture widgets. To exercise this, set the env.var. QT_WIDGETS_RHI=1. This picks a platform-specific default, and can be overridden with QT_WIDGETS_RHI_BACKEND. (in sync with Qt Quick) This can eventually be extended to query the platform plugin as well to check if the platform plugin prefers to always do flushes with a 3D API. QOpenGLWidget should work like before from the user's perspective, while internally it has to do some things differently to play nice and prevent regressions with the new rendering architecture. To exercise this better, the qopenglwidget example gets a new tab-based view (that could perhaps replace the example's main window later on?). The openglwidget manual test is made compatible with Qt 6, and gets a counterpart in form of the dockedopenglwidget manual test, which is a modified version of the cube example that features dock widgets. This is relevant in particular because render-to-texture widgets within a QDockWidget has its own specific quirks, with logic taking this into account, hence testing is essential. For existing applications there are two important consequences with this patch in place: - Once the rhi-based composition is enabled, it stays active for the lifetime of the top-level window. - Dynamically creating and parenting the first render-to-texture widget to an already created tlw will destroy and recreate the tlw (and the underlying window). The visible effects of this depend on the platform. (e.g. the window may disappear and reappear on some, whereas with other windowing systems it is not noticeable at all - this is not really different from similar situtions with reparenting or when moving windows between screens, so should be acceptable in practice) - On iOS raster windows are flushed with Metal (and rhi) from now on (previously this was through OpenGL by making flush() call composeAndFlush(). Change-Id: Id05bd0f7a26fa845f8b7ad8eedda3b0e78ab7a4e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Miscellanea fixes for QT_TYPESAFE_FLAGS in our headersGiuseppe D'Angelo2022-03-071-3/+3
| | | | | | | | | | | | | | | | | | | | | In preparation for adding it to headersclean. Some remarks: * QStandardItemModel builds just fine (QFlags has comparison operators against literal zero); the warning we however get is about 0 converted to a null pointer constant. There's nothing we can do about that one (even <compare> gives such a warning). * Several code was depending on flags->int conversions. Add toInt(), but also cast again to the expected type to avoid warnings in case toInt() returns unsigned int. * Ported to explicit casts to bool rather than test(Any)Flag to minimize confusion for people unfamiliar with the test*Flag methods. Change-Id: I5be280ac33a0b38e2680096f0e79129fd55ba241 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Fix Q_FLAG declaration over enumerationsGiuseppe D'Angelo2022-03-021-1/+1
| | | | | | | | | | One should use Q_ENUM, not Q_FLAG, to mark an enumeration. Q_FLAG should go on the respective flag type. Change-Id: I16cd5c0d405c3db1951569b72805fdae18898c45 Pick-to: 5.15 6.2 6.3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Implement QFormLayout::set/isRowVisibleVolker Hilsheimer2022-02-242-7/+200
| | | | | | | | | | | | | | | | | | | | | | | Hiding a row in a form layout is inconvenient to do as access to the widgets in each row is cumbersome. In addition, a row might include a layout for the label or the field column, and we can't hide layouts and instead need to navigate to the widgets inside the layout. And even if an application developer does all that, the spacing calculation doesn't ignore hidden rows. Add setRowVisible and isRowVisible APIs with the usual overloads. Implement the logic to traverse a layout item to its contained widgets, so that they are explicitly hidden when a row is hidden, and skip hidden rows in the spacing calculation. [ChangeLog][Widgets][QFormLayout] New APIs setRowVisible and isRowVisible to hide and show rows in a form layout. Fixes: QTBUG-6864 Change-Id: I6af98409802f331c4523e91d7dac8a97762c579d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Make QGuiApplicationPrivate::lastCursorPosition.toPoint() safe to useShawn Rutledge2022-02-221-1/+1
| | | | | | | | | | | | | | | | | | | QGuiApplicationPrivate::lastCursorPosition is initialized with qInf(); so before Qt has seen a mouse move event, attempting to convert to QPoint is an error. It's best to have one place where we do the qIsInf() check rather than several (and otherwise prefer using the QPointF as-is rather than converting to QPoint at all). Introduce a helper class that contains a QPointF, and provides a safe conversion to QPoint, as well as simple accessors for clients using QPointF. Fixes: QTBUG-52472 Task-number: QTBUG-45045 Change-Id: I83fad1bfb658e03fa876344552f1d5bb751d9f81 Pick-to: 6.2 6.3 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Core: Remove 'properties' featureKai Köhne2022-02-141-2/+0
| | | | | | | | | | | | | Even QtCore alone cannot be built without the properties feature since Qt 5.5. While fixing this is easy, other modules like dbus, networking are also using QObject::property() and friends liberally. All in all I doubt that anybody will miss the feature (otherwise it would have been fixed in the last decade). Change-Id: Iaf3cc20bda54ee2ff3b809fac8fa82b94ecc88c0 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Reduce qaccessible includesFabian Kosmale2022-02-091-0/+3
| | | | | | | | | | Forward declare some types in qaccessiblewidgetfactory_p.h instead of including qaccessible.h. In turn, qapplication.cpp which relied on transitive includes now needs to include qaccessible_base.h. Change-Id: I8ac00d45a7ffccd84769fb210f29364a45bcd59e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add a QHoverEvent ctor taking global mouse position; deprecate the otherShawn Rutledge2022-02-031-9/+9
| | | | | | | | | | | | | | | | | The QSinglePointEvent ctor assumes that the given globalPos is correct, so it was wrong that the QHoverEvent ctor passed along a local position as global. It's better to require globalPos as an argument; and in fact it seems that everywhere we construct a QHoverEvent, global position is available, or possible to get by transformation (which is better than resorting to QCursor::pos()). Also, don't convert to QPoint: pointer events have qreal resolution and there's no reason to truncate them. Fixes: QTBUG-100324 Change-Id: I919455da36265988d3d149eb97563c9ed0d2c660 Pick-to: 6.3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QGuiApplication: invert meaning of qt_is_gui_usedMarc Mutz2022-02-022-5/+5
| | | | | | | | | | | | | | | | | | The default value was true, which is non-zero, forcing the variable out of the BSS and into the DATA segment. Fix by inverting the meaning so the default value can be false. Since qt_is_gui_unused sounds a bit complicated, however, take a cue from the variable's only writer and rename it qt_is_tty_app. Pick-to: 6.3 Change-Id: I198e9786f7e71178d69fecb5179287bf39b3a1d6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Don't include qeventpoint_p.h from qevent_p.hMarc Mutz2022-01-142-0/+2
| | | | | | | | | | | The header no longer uses QMutableEventPoint. Fix TUs that relied on the transitive include. Task-number: QTBUG-99615 Pick-to: 6.3 Change-Id: Iae4ff34ea708304fcd365fd763875dd4a97a1cf8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Port the last user of QMutableSinglePointEvent::mutableEvent()Marc Mutz2022-01-141-1/+1
| | | | | | | | | | | ... to the static setters of QMutableEventPoint. Remove the mutableEvent() function. Task-number: QTBUG-99615 Pick-to: 6.3 Change-Id: If4d3decae67baff41e23e7e9eaed3f3035fab595 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't return an associated screen for embedded widgetsVolker Hilsheimer2022-01-131-0/+5
| | | | | | | | | | | | | | | Widgets embedded in a graphics view via QGraphicsProxyWidget don't have an associated screen, even though they are top level windows in the widget hierarchy. Their screen has to be based on the screen of the toplevel widget they are embedded in. This fallback is taken care of by QWidget::screen already. Task-number: QTBUG-20531 Pick-to: 6.3 Change-Id: I77af092b2f8e6322662499be464eec40cfd9ac1c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QApplication: port manual users of QMutableEventPointMarc Mutz2022-01-131-2/+2
| | | | | | | | | | | | | | ... to new static setter API, which doesn't depend on undefined behavior. These users didn't use QMutableEventPoint::from(), but static_cast<>, so they were only found when the non-static setters were removed, locally. Task-number: QTBUG-99615 Pick-to: 6.3 Change-Id: I37faf17b2b180e0f6e8bb4e5f46951a2cc29678d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QMutableEventPoint: add static overloads of settersMarc Mutz2022-01-082-20/+20
| | | | | | | | | | | | | | These overloads don't require a cast from QEventPoint to QMutableEventPoint, thus avoiding undefined behavior. Port easy users of QMutableEventPosition::(const)from() to the new API. Pick-to: 6.3 Task-number: QTBUG-99615 Change-Id: I4e9228322134ef7c712ca478ee8286466efc3585 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix qobject_cast on partially destroyed QWidget/QWindowGiuseppe D'Angelo2022-01-052-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QWidget and QWindow use bits in QObjectPrivate to provide for a couple of shortcuts -- one in qobject_cast, and another in the isWidgetType() / isWindowType() functions in QObject. These can be optimized by simply looking at the bits, without actually doing more expensive runtime casts. These bits were set on construction, but not unset on destruction. The result was for instance that destroying a QWidget would report that the object was still a QWidget when ~QObject was reached. Fix this 1) by setting the bits only when QWidget / QWindow constructors start; 2) by resetting the bits once ~QWidget / ~QWindow are completed. Technically speaking this is not 100% correct in the presence of data members, but luckily those classes don't have any. Amend an existing test for QWidget (whose comment said exactly the opposite of what the test actually did) and add a test for QWindow. Some other code was wrongly relying on isWidgetType() returning true for destroyed QWidgets; amend it as needed. [ChangeLog][QtCore][QObject] Using qobject_cast on partially constructed or destroyed QWidget/QWindow instances now yields correct results. Similarly, using the convenience isWidgetType() / isWindowType() functions now correctly return false on such instances. Before, qobject_cast (and the convenience functions) would erroneously report that a given object was a QWidget (resp. QWindow) even during that object's construction (before QObject's constructor had completed) or destruction (after QWidget's (resp. QWindow's) destructors had been completed). This was semantically wrong and inconsistent with other ways of gathering runtime type information regarding such an object (e.g. dynamic_cast, obj->metaObject()->className() and so on). Pick-to: 6.3 Change-Id: Ic45a887951755a9d1a3b838590f1e9f2c4ae6e92 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Deliver context menu event with correct coordinates to widgets in popupsVolker Hilsheimer2021-12-221-1/+2
| | | | | | | | | | | | | | If a popup is open, Qt delivers events to the popup child under the mouse, so we need to correctly translate the local position of the context menu event to that child's coordate system. This is already done correctly for regular mouse events, so use the same logic here. Fixes: QTBUG-99371 Pick-to: 6.2 6.3 5.15 Change-Id: Ief24c755e76d4d1aa2304b06662ed26ae309f684 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix widget gesture grabbingVolker Hilsheimer2021-12-112-6/+11
| | | | | | | | | | | | | | | | | | After 7369c31ca1f446e81eda1c93ba13767ffcd83efe, unaccepted touch points were not grabbed anymore in calls to activateImplicitTouchGrab. However, gesture recognition relies that widgets for which a gesture has been partially recognized grab also unaccepted touch points. Add a parameter to allow the implicit grabbing to take place also for unaccepted event points. Add test case that replays touch events similar to what Squish is doing, and fails without this fix. Pick-to: 6.2 Change-Id: Idb0b20301b1827be57a03013a59043d97c2ee7b6 Reviewed-by: Stefan Gehn <stefan.gehn@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add unit test for moving of opaque widgetsVolker Hilsheimer2021-12-081-2/+3
| | | | | | | | | | | | | | | Expose QWidgetRepaintManager's data structures so that we can write unit tests, and verify that they are correct after moving opaque widgets (which triggers the accelerated move code path). Improve the compareWidget logic to not rely on screen grabbing (which requires permissions), but instead use QPlatformBackingStore's toImage function, which is faster and more reliable, and also doesn't require us to show the UI we want to grab full screen in order to avoid issues with overlapping windows etc. Change-Id: Iff2ea419f03a390ab6baca26814fef6ff45f7470 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Code tidies: improve variable naming and add const where possibleVolker Hilsheimer2021-12-081-19/+17
| | | | | | | | | Remove obsolete check for valid sourceRect, we never get into the accelerated code path if it's not. Pick-to: 6.2 Change-Id: I872685fca8cba3a09ed856d727d5baafddee161b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix incorrect rendering when moving widget into screenVolker Hilsheimer2021-12-081-1/+1
| | | | | | | | | | | | When the widget we are moving in was previously outside of its parent's clip rect, then we cannot use the accelerated move code path, as there are no pixels to bitBlt from the previous to the new area. Pick-to: 6.2 Task-number: QTBUG-26269 Task-number: QTBUG-98151 Change-Id: I324c6111de27cdd14cf8de8632a980aa351cc123 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Revert optimizations and fixes for moving/scrolling overlapped widgetsVolker Hilsheimer2021-12-072-80/+28
| | | | | | | | | | | | | | | | | This reverts the QtWidgets changes made in commits 22634e00794e72d68e7578e1962f9f2023870749 and 5b09346cf4322704a866f253b911d467c40df3ba while keeping the auto tests introduced in the former commit. Both commits introduced rendering errors when moving widgets out of or into areas in which they are obscured. Before we apply any further optimizations to this code we need thorough auto test coverage. Task-number: QTBUG-98151 Task-number: QTBUG-26269 Pick-to: 6.2 Change-Id: I9cb82b73776daed59ea0e9f51ff7ddef1c7265b6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QSizePolicy: make qHash() a hidden friendMarc Mutz2021-12-032-5/+3
| | | | | | | | | | | | | | Less noisy compiler error messages. [ChangeLog][Potentially Source-Incompatible Changes][QSizePolicy] qHash() is now a hidden friend and can only be called by unqualified (qHash(sp)), not by qualified lookup (as in, say, ::qHash(sp) or QT_PREPEND_NAMESPACE(qHash)(sp)). Task-number: QTBUG-98863 Change-Id: I37d26c661c2d8bb74350eb9378bd19fa426678d2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Skip disabled proxy widgets when (back)tabbingAlexander Volkov2021-11-191-1/+4
| | | | | | | Fixes: QTBUG-98137 Pick-to: 6.2 5.15 Change-Id: If52053dce361b130ef7dcfaf747710d8ceb9bbcd Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Make sure we paint overlapped children and siblings when moving farVolker Hilsheimer2021-11-151-11/+13
| | | | | | | | | | | | | | | | | | | | In paintAndFlush, QWidgetRepaintManager subtracts opaque children if the target isn't overlapped and isMoved is set to true. So in moveRect, set isMoved to true after the blitting of movable areas, and reset it to false if we have overlapped sibling or child regions. Otherwise, moving so far that sourceRect is invalid (none of the original pixels are visible after the move) we end up in a code path that sets isMoved to true even with overlapping children or siblings, which then breaks paintAndFlush's assumptions. Reuse the test case written by Sergiy Korobov <tiamatenko@gmail.com> in earlier attempts to fix this bug. Fixes: QTBUG-26269 Pick-to: 6.2 Change-Id: If7443863f5eee79a80220cd587522122f42a21e4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QWidget: always handle IM queriesRichard Moe Gustavsen2021-11-121-2/+1
| | | | | | | | | | | | | | | | | A widget (e.g QLineEdit) will set WA_InputMethodEnabled to false if it's read-only. But it can still contain selected text (e.g from a mouse drag). In many cases, it therefore makes sense to be able to query the focus object for what that selection is, e.g to be able to show selection handles from the QPA plugin (iOS/Android). Therefore, remove the check if a widget has WA_InputMethodEnabled, and always process the query. The caller can always check this flag himself (or Qt::ImEnabled) before sending the query, if needed. Task-number: QTBUG-91545 Change-Id: Ia3dfa289283b5c157ba47cf0b508f9fddadd2861 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Calculate effect bounds when drawing widget graphics effectAntti Määttä2021-10-271-4/+5
| | | | | | | | | | | | | Calculate effect bounds for the updated region when drawing the effect so that the whole affected area gets updated. The effect bounds have already been added to the region so it doesn't need to be handled in the drawing function. Pick-to: 6.2 5.15 Fixes: QTBUG-96240 Change-Id: I0c317311622e6299fb1a3015541408d1d83c93de Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't fire shortcut if the action only lives in an unreachable submenuVolker Hilsheimer2021-10-251-1/+1
| | | | | | | | | | | | | | | | | Menus can be represented by a menu action, and if that menu action has been hidden or disabled, then the submenu is not accessible from the parent menu or menu bar to which it was added. Don't walk the menu action chain further when checking whether the shortcut should trigger. Note that this is unrelated to the menu being visible or not; we obviously want to trigger shortcuts for actions that only live in a menu that has not been shown, otherwise the shortcut would be rather pointless. Pick-to: 6.2 Fixes: QTBUG-25743 Change-Id: I48735e17352989bbc84a72263e4828f519b78095 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix warnings due to enums in QSizePolicyFan RuiJie2021-10-211-2/+3
| | | | | | | | | | | | | | gcc 11 generates warnings as "bitwise operation between different enumeration types 'QSizePolicy::Policy' and 'QSizePolicy::PolicyFlag' is deprecated" in C++20. Fixes: QTBUG-93810 Pick-to: 6.2 5.15 Change-Id: If8a796b33a772cc1a561eb0b6bc4def8f9f54bc0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Centralize maybeLastWindowClosed checking in QWindowTor Arne Vestbø2021-10-203-16/+17
| | | | | | | | | | | | | | | | | Instead of plumbing QWidgetWindow close events via handleCloseEvent, we just implement closeEvent directly. This allows QWindow do save the state of the window/widget before the close event, so that we know whether we should trigger lastWindowClosed handling, even if the window was deleted as a result of the close event. This also relieves QGuiApplication and QApplication from dealing with the close logic in their notify functions, so that these functions can focus on the propagation of events -- not how the event is handled. Change-Id: I8b586b53a53b1df1d8630c1acb635c60f191bb4b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't render widget to backing store if its parent has graphics effectAntti Määttä2021-10-191-1/+14
| | | | | | | | | | | | If widget parent has graphics effect, it can't render directly to the backing store, because the backing store needs to be updated from the parents effect drawing instead of the widget drawing. Pick-to: 6.2 5.15 Fixes: QTBUG-96240 Change-Id: Ib9b55547f9e5538f32837ec9df45d29fa68d7c1b Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QtWidgets: remove set-but-unused variablesThiago Macieira2021-10-161-2/+0
| | | | | | | | | Found by clang 13: qlayoutengine.cpp:80:9: warning: variable 'cMax' set but not used [-Wunused-but-set-variable] Change-Id: Iea05060bc2c046928536fffd16adf54d1527e657 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Deduplicate lastWindowClosed handlingTor Arne Vestbø2021-10-163-47/+9
| | | | | | | | | | | | | | | | | | | | | | | Whenever a window was closed, we had logic to check if it was the last window, and if so emitted lastWindowClosed and then tried to quit the application. But the automatic quit process also checked if there were any remaining windows, as this process could be triggered as a result of a QEventLoopLocker going out of scope. The two paths now share the same logic for determining if there are any remaining windows. The docs have been updated to reflect the original intent of the logic, dealing only with primary windows (top levels without a transient parent). This was how both the original code paths implemented their logic. For historical reasons the Qt::WA_QuitOnClose attribute is closely tied to the lastWindowClosed signal, and isn't merely limited to controlling whether we try an automatic quit when the last window closes. For now this behavior has been kept, but the docs have been updated to clarify how the attribute is handled in practice. Change-Id: If3d06b065236aad2e59e9091cac3146bc4cf79f6 Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove unused parentWidget variable in QWidgetPrivate::handleCloseTor Arne Vestbø2021-10-161-1/+0
| | | | | | | | | It was a leftover from when the quitOnClose logic was duplicated in the handleClose function. Change-Id: I38903b7e30ef1cf1d0dce87f61097a83259aea8e Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>