summaryrefslogtreecommitdiffstats
path: root/src/widgets/kernel
Commit message (Collapse)AuthorAgeFilesLines
* IM: Don't let all widgets support IM by defaultRichard Moe Gustavsen2022-07-011-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new property Qt::ImEnabled was added in Qt 5.3. Since the already existing widgets with IM support (3rd party included) didn't implement this property, QWidget got the fall back logic that if a widget was queried for Qt::ImEnabled, and the returned QVariant was invalid (the widget didn't implement it), we would, for backwards compatibility with Qt 4, return "true" (meaning that the widget supports IM). But a side effect from this fallback logic, is that now any widget that doesn't implement ImEnabled (or input methods at all) report that they support IM. This will confuse platforms like iOS, which uses ImEnabled to decide if the input panel should show, and if text selection tools should be enabled. The result is therefore that if you click on a QPushButton, the input panel will open. This patch will implement a more careful strategy to check if a widget implements IM, if ImEnabled is missing. Rather than saying that all widgets that don't implement ImEnabled supports IM, we now require that the widget also returns a valid QVariant for Qt::ImSurroundingText. We assume then, that a widget that doesn't do so will anyway not be in need of input method support from the platform. Fixes: QTBUG-104527 Pick-to: 6.4 6.3 6.2 Change-Id: Ib391fd1daae92c4325e9ccb59730fbdd7c9328fc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QBoxLayout: Add assertion that catches out of bounds insertion indicesMarcel Kummer2022-06-181-0/+1
| | | | | | | | | | | | | | | As of Qt6, QList will assert that an insertion index is in range of existing values. QBoxLayout interprets negative indices as "append at the end". That part is covered. Indices larger than the number of items in the layout would trigger the assertion in QList, but after the insert method had returned. That would make it hard to debug. This change asserts the index range before inserting, thus making it easier to spot the problem. Fixes: QTBUG-103775 Change-Id: Ida099f785263fe8a5c8a1d0a48c4ff87713549b4 Pick-to: 6.2 6.3 6.4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QBoxLayout: Pull out handling for negative insertion indicesMarcel Kummer2022-06-171-16/+14
| | | | | | | | | | | This snippet occurs in every insert function further down. Let's pull it out in preparation for adding an assertion that the index is in range, which would also need to be added to every insert function. Fixes: QTBUG-103775 Change-Id: I419f57434f860df4c947853ac307826994f0198b Pick-to: 6.2 6.3 6.4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Accessibility: don't emit focus change when reason is window activationVolker Hilsheimer2022-06-161-5/+9
| | | | | | | | | | | | | | | | | | | | If a window becomes active, then the accessibility system gets informed about that already. Qt puts focus on the focus child of the activated window afterwards, and if this emits another accessibility event, then accessibility clients like Windows Narrator will stop reading the activated window, and instead read about the focused widget. This makes dialogs like message boxes poorly accessible. Accessibility clients already know that a window became active, and can query Qt about the focused child within that window. Amend test case. Fixes: QTBUG-101585 Pick-to: 6.4 6.3 6.2 Change-Id: I2d6bff7c415a6f29c4a4f7f4e4be38079fb976ca Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix typos in docs and commentsKai Köhne2022-06-151-1/+1
| | | | | | | | | Found by codespell Pick-to: 6.4 Change-Id: Ie3e301a23830c773a2e9aff487c702a223d246eb Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Replace QT_NO_ACCESSIBILITY with QT_CONFIG(accessibility)Allan Sandfeld Jensen2022-06-157-21/+21
| | | | | | | Pick-to: 6.4 Change-Id: Iee4bd8970810be1b23bdba65a74de912401dca65 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Add support for painting at integer DPR with downscaleMorten Sørvig2022-06-141-2/+13
| | | | | | | | | | | | | | | | | | | Enable by setting QT_WIDGETS_HIGHDPI_DOWNSCALE=1 and QT_WIDGETS_RHI=1. This will make the backing store and painter operate at the next highest integer DPR in cases where QWindow::devicePixelRatio() returns a fractional value. The backing store image will then be downscaled to the target DPR at flush time, using the RHI flush pipeline. [ChangeLog][QWidgets] Added experimental support for always painting at an integer device pixel ratio (rounding the DPR up if necessary), followed by a downscale to the target DPR.Enable by setting QT_WIDGETS_HIGHDPI_DOWNSCALE=1 and QT_WIDGETS_RHI=1. Pick-to: 6.4 Task-number: QTBUG-86344 Change-Id: Id5b834a0e3499818b0b656161f5e0c38a6caa340 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Make rhiFlush() support custom source DPRMorten Sørvig2022-06-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | The rhiFlush() implementation currently assumes that QWindow->devicePixelRatio() is the correct scale factor for transforming device independent window geometry to source geometry. However, this assumption does not hold if/when we add support for drawing to a rounded-up DPR, with a downscale later in the rhiFlush implementation. Fix this by adding a sourceDevicePixelRatio argument to rhiFlush(), which is set to either QWindow::devicePixelRatio() or QWidget::devicePixelRatio(), depending on from where it is used. Change deviceRect() and friends in qbackingstoredefualtcompositor.cpp to be scale*() functions instead which take a scale factor instead of a QWindow. Update call sites to use srouceDevicePixelRatio where that makes sense. Pick-to: 6.4 Change-Id: Idb7b1e2f36816a201e00f0defe100d2dc079cb17 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* QApplication: Remove QApplicationPrivateBase porting macroThiago Macieira2022-06-132-4/+2
| | | | | | | | | This was last used in 2011, before Qt 5.0 release, when QPA was yet another windowing system, not the only option. Change-Id: Ia4a094014ddb48cc9f6dfffd16f83aad1b7109e7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Q*ApplicationPrivate: remove unused "flags" argumentsThiago Macieira2022-06-142-5/+5
| | | | | | | | | | | | | | | | They weren't flags. They were the version of Qt that was used in compiling the application itself. The protection against rollback isn't necessary any more, since qversiontagging.h, which applies to everything and not just the main application binary. And using them to make decisions on functionality or behavior is misguided (see previous commit). This commit does not deprecate the front-end classes' argument. In the future, we may find some need for them. Pick-to: 6.4 Change-Id: Ia4a094014ddb48cc9f6dfffd16f83a7b58ff95d3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Refactor if-else snake into switch statementVolker Hilsheimer2022-05-241-19/+20
| | | | | Change-Id: I597d5cbdddf4a2fbbe8b9de2ae252cdeadce9d11 Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
* Fix QWidget::metric to use widget screen dpr instead of app-dprThorbjørn Lund Martsum2022-05-241-13/+4
| | | | | | | | | | | | | Use the widget screen dpr in calculations rather than qApp->devicePixelRatio(). The screen may have been directly set (without the window handle being initialized) Task-number: QTBUG-103309 Task-number: QTBUG-49663 Task-number: QTBUG-101947 Task-number: QTBUG-102982 Change-Id: I2af2073640b171baf68575e3bc93b29b6a9a471d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix separate delete of window and windowcontainerAllan Sandfeld Jensen2022-05-232-6/+30
| | | | | | | | | | | | The documentation says we can change window parent to avoid the widget deleting the window. That didn't work as the widget didn't get the child-removed event as it wasn't the parent. This patch instead uses an event filter on the set parent. Pick-to: 6.3 6.2 Change-Id: I1f61d1832fcf3257722f305beeefd8f1abf1f656 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* 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>