summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
...
* QGuiApplication: Fix condition for when doubleclick events are triggeredJan Arve Sæther2023-11-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QGuiApplicationPrivate::processMouseEvent() requires the following conditions to be met in order to trigger a double click event: 1. The same button should be pressed (kept in mousePressButton member) 2. The time between two press events should not exceed doubleClickInterval 3. Movement between presses shouldn't be bigger than doubleClickDistance Unfortunately, when we are processing *synthesized* mouse events (from touch), in order to check criterion 2) we cannot rely on QPointingDevicePrivate::pointById(0)->eventPoint.pressTimestamp(); because this was already updated in QGuiApplication::processTouchEvent(), so it does not any longer reflect the *previous* press timestamp, but the current one. Therefore we could not reliably calculate the time between the previous press and the current press (in fact, it never exceeded the doubleClickInterval condition) I suspect this occurs with all touchscreens, but at least it was reproduced with e.g. a NVIDIA Terra / Thinkvision touch screen on Windows 11 and Dell Express SVC touch screen on Windows 11. => Since QGuiApplication is a singleton, add a static local variable to remember the time stamp of the last processed press event. Autotesting has been modelled in PS7. However, QTest::touchEvent is unable to synthesize hardware specific detection latency and stray touch events, which actually reproduce the issue. => Not adding an autotest. Fixes: QTBUG-112479 Fixes: QTBUG-119032 Fixes: QTBUG-100688 Pick-to: 6.6 6.5 Change-Id: Idc97fb9d49ed334f56d702d420451fc062e9b5a9 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* QGuiApplication: check return value of platformTheme::palette()Christian Ehrlicher2023-11-141-1/+2
| | | | | | | | | | | Under some circumstances (e.g. setDesktopSettingsAware(false) on windows) it may happen that the call to platformTheme::palette() returns a nullptr which is not checked before dereferencing the pointer. Therefore add a check for this to avoid a crash. Fixes: QTBUG-111527 Change-Id: I6443d5d1a9b813f499d8f65b4fee55b0b8299b16 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Beautify QGuiApplication::event()Axel Spoerl2023-11-101-5/+9
| | | | | | | | | | Replace if/elseif with a switch. Task-number: QTBUG-112479 Task-number: QTBUG-119032 Pick-to: 6.6 6.5 Change-Id: Iff29fde6a9b9a16357b26cf90009fec7c9826349 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix build with -no-feature-shortcutTasuku Suzuki2023-11-071-0/+2
| | | | | Change-Id: I43b95991fcf37ac8b125b176a59518e6a81e11dc Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* QMessageBox: Detect modifications to standard button textTor Arne Vestbø2023-10-312-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The addButton(StandardButton) and button(StandardButton) APIs return a QAbstractButton, that the user can in theory modify to their heart's content. This causes problems when the native dialog backend is not aware of these modifications. We documented this limitation in e9a1c5321, but it turns out to be more common than we first though. In particular, a typical case is modifying the text of the button. We now try to detect if the button has a non-standard text, and if so turn it into a custom button when passing it on to the native backend. From the point of view of QMessageBox it's still a standard button, and will be reported as such in the result of exec(). To make this work the QMessageDialogOptions::CustomButton needs to learn about custom button identifiers, so we can pass the original standard button though. This moves us closer to a world where the QMessageDialogOptions represent both standard buttons and custom buttons using the same structure, which is what we want anyways, so that we e.g. respect the added order of standard buttons with the same role. Pick-to: 6.5 6.6 Change-Id: Ifb7f7bd537fe71293f14ef6a006999e350bd0b52 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Teach QMessageDialogOptions about default and escape buttonsTor Arne Vestbø2023-10-262-0/+34
| | | | | | | | | | | | | | | | | | There's logic in QMessageBox to resolve the default and escape button if not set by the user. And the user may of course override these. We now propagate the resulting buttons via the dialog helper, and pick them up in the macOS native dialog backend. The only common information we have between the standard buttons and custom buttons is the button identifier, which for standard buttons is the enum value, and for custom buttons is an auto generated identifier. The same identifier is used when reporting the clicked button from the native dialog helper. Fixes: QTBUG-118308 Pick-to: 6.6 6.5 Change-Id: I5ca45604b51f0bbf74e56134d7b55bb8911f3563 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Avoid creating child windows twice when already visibleTor Arne Vestbø2023-10-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | When a child window is made visible without its parent having been created yet, we defer creating and making the child visible until the parent is created. But if a child window is explicitly created, we create the parent first. And creating the parent will in turn apply visibility to all children that had their visibility deferred. Which includes creating the child. This results in child -> parent -> child creation recursion, which means that when we return from creating the parent window we already have a platform window for our child, and should bail out. Pick-to: 6.6 6.5 Change-Id: I11dc4864b57f031de2cca70b79cdfc057d4fbd0d Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* qevent.h: don't include <QPointer>, fwd-declare itMarc Mutz2023-10-181-1/+1
| | | | | | | | | | | | | The header uses QPointer in-name-only, so it doesn't need to include the class' header file. A forward-declaration suffices. [ChangeLog][Potentially Source-Incompatible Changes] The headers qevent.h and qfuture.h no longer include the header qpointer.h. Change-Id: I8d3c3b56f5928a0745a523abf5df3b8106dc15ee Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Remove unnecessary code in QCursorJiDe Zhang2023-10-181-20/+10
| | | | | | | | | Dont't checks before call QCursorData::initialize(). The inside of QCursorData::initialize() already checks initialized. Change-Id: I4b34218132df9decf7d04dcc31e873daf300ffe6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io>
* Include what you need: <QPointer>Marc Mutz2023-10-129-0/+19
| | | | | | | | | | | | | | | | | | | | | | | All these TUs relied on transitive includes of qpointer.h, maybe to a large extent via qevent.h, though, given that qevent.h is more or less the only public QtBase header that includes qpointer.h, something else seems to be at play here. Said qevent.h actually needs QPointer in-name-only, so a forward declaration would suffice. Prepare for qevent.h dropping the include. The algorithm I used was: If the TU mentions 'passiveGrabbers', the name of the QEvent function that returns QPointers, and the TU doesn't have qpointer.h included explicitly, include it. That may produce False Positives, but better safe than sorry. Otherwise, in src/, add an include to all source and header files which mention QPointer. Exception: if foo.h of a foo.cpp already includes it, don't include again. Task-number: QTBUG-117670 Change-Id: I3321cccdb41ce0ba6d8a709cea92427aba398254 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Allow QPalettePrivate to be used outside of qpalette.cppMitch Curtis2023-10-122-18/+15
| | | | | | | | | | | | | | | | We need access to bitPosition in order to check if a role was set. This fixes the following build error: [...] qwindowstheme.cpp(1150): error C2220: the following warning is treated as an error [...] qwindowstheme.cpp(1150): warning C4506: no definition for inline function 'QPalette::ResolveMask QPalettePrivate::bitPosition(QPalette::ColorGroup,QPalette::ColorRole)' Amends 417878904b39b444632df18f7dd37bcb073c0467. Task-number: QTBUG-116826 Change-Id: I815c7e961198ab93b6ed6132badc2ec693522472 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Use QtGui to match QWindow based shortcuts, even when QApplication is usedTor Arne Vestbø2023-10-112-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a QShortcut is registered with a QWindow as its parent, but QApplication is used, we end up in QApplicationPrivate::createShortcutPrivate(), and create a QtWidgetsShortcutPrivate that implements shortcut context matching via qWidgetShortcutContextMatcher. The problem is that qWidgetShortcutContextMatcher expects the windows to be QWidgetWindows, which meant that plain QWindow based shortcuts would always fail. This can happen for example if a QApplication is used in Qt Quick to provide dialog fallbacks, but QShortcuts are otherwise used with plain QWindows, or QQuickWindows e.g. We now defer the check of whether there's an active (widget) window, and fall back to QtGui's simpleContextMatcher in case we don't find a QWidget, QAction, or QGraphicsWidget shortcut owner to handle the matching for. Note: We don't support shortcut matching for QAction in QtGui, but this is left for another day. There is also a discrepancy between how QtGui and QtWidgets handles Qt::ApplicationShortcut. The former will treat it as a match even if there is no active QWindow, while the latter requires that there's an active widget window. Fixes: QTBUG-116221 Change-Id: I487995f2e660a40f6556828b84a521d81a58f1b6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Export QPalettePrivateAxel Spoerl2023-10-111-1/+1
| | | | | | | | | Q_GUI_EXPORT the private header to access it from outside Gui. Task-number: QTBUG-116826 Pick-to: 6.6 Change-Id: I6aaabe2df7ebebd7b53662f47a52c748344067bc Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Add verbose debug logging for QKeyMapper::possibleKeys()Tor Arne Vestbø2023-10-111-0/+12
| | | | | | | Generalized from the logging used in the Apple key mapper. Change-Id: I61cc120e31b72995071756961d36f6a7fae14553 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Make QKeyMapper::possibleKeys() return list of QKeyCombinationsTor Arne Vestbø2023-10-113-11/+8
| | | | | | | | | Having the explicit type instead of the opaque int makes it clearer what we're dealing with. Task-number: QTBUG-116873 Change-Id: I19e42ed329e15ab25a958602ecfb99b1c9d52a99 Reviewed-by: Liang Qi <liang.qi@qt.io>
* QKeySequence::toString(): Treat Modifier+Qt::Key_Unknown as empty stringTor Arne Vestbø2023-10-091-3/+3
| | | | | | | | | | | | We were already doing this for a key combination without modifiers, but now we do the same for e.g. Control+Unknown. This matches the behavior we have for QKeySequencePrivate::decodeString(), where we return Qt::Key_Unknown if we can't resolve the key, even if we have resolved some valid modifiers, e.g. "Meta+Trolls" as in the tst_QKeySequence::parseString() test. Change-Id: I238e29276e6ce356ae60c67585739587fa388f07 Reviewed-by: Liang Qi <liang.qi@qt.io>
* Teach QKeySequencePrivate about QKeyCombinationTor Arne Vestbø2023-10-092-19/+22
| | | | | | | | | | Being explicit about whether we're dealing with QKeyCombination or a plain Qt::Key helps understand the code. Keys are still stored as ints though. Change-Id: I2cb7bf2c5fabcecbd4dd3e99ba6240fb1910dcc7 Reviewed-by: Liang Qi <liang.qi@qt.io>
* QKeySequence: Remove unused private helper methodsTor Arne Vestbø2023-10-092-20/+0
| | | | | | | The functionality is available in QKeySequencepPrivate still, if needed. Change-Id: Iefa2e5b31a550fd2a419d2aee028ce4c1ddfb7a2 Reviewed-by: Liang Qi <liang.qi@qt.io>
* Long live QPlatformKeyMapper!Tor Arne Vestbø2023-10-066-9/+113
| | | | | | | | | | | | | | The QKeyMapper class never got a platform integration companion. As we might be adding more functionality here in the future, let's fix that now, instead of adding more hooks directly to the platform integration class. The QKeyMapper will soon update its possibleKeys signature to return QKeyCombination, but for now transform the result. Change-Id: I88ef498180b2a8a7937a74627b7eb6b5156e872a Reviewed-by: Liang Qi <liang.qi@qt.io>
* Automatically reflect new input context input direction when locale changesTor Arne Vestbø2023-10-062-0/+14
| | | | | | | | | | | | All platforms except Wayland fail to check for input direction change when the locale changes, and only emitLocaleChanged. We can simplify this for the platforms by checking if the new locale caused a change in input direction, and if so emit inputDirectionChanged on their behalf. Change-Id: I84d8df9392db5e716f5c277d0cc9e17e5a21783f Reviewed-by: Liang Qi <liang.qi@qt.io>
* Make QKeyMapper::possibleKeys's event argument constTor Arne Vestbø2023-10-022-2/+2
| | | | | | | To match the QPA layer (QPlatformIntegration, QPlatformKeyMapper). Change-Id: If1b4817eb334c6cdf1ccd587794701245076bd2f Reviewed-by: Liang Qi <liang.qi@qt.io>
* Support more verbose debug output for QKeyEventTor Arne Vestbø2023-10-021-0/+4
| | | | | | | Sometimes it's useful to know the scan code and virtual key as well. Change-Id: Ic120189470a9ff44a5cb7f6dcc1405654136424f Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Add catch-all DPR update to expose event handlingMorten Sørvig2023-10-023-3/+13
| | | | | | | | | | | | | | The platform plugin should already DPR (or DPI) change events, however if that does not happen we update in the expose event as well as a last resort to make sure the window's DPR value is in sync. Also print a warning and ask for a bug report. Pick-to: 6.6 6.0 Change-Id: Ibb144f163281a28216c2fa3353ed50237e91ce25 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Remove QKeyMapper::changeKeyboard()Tor Arne Vestbø2023-09-302-16/+0
| | | | | | | | | | | | | | | | | | | As described in QTBUG-27681, we no longer send KeyboardLayoutChange events in Qt 5 and up. We have QInputMethod::localeChanged, but that doesn't cover the cases where the input language stays the same, but the layout is changed. None of our widgets react to KeyboardLayoutChange these days, but ideally we should send KeyboardLayoutChange if we can plumb it from the platforms. However that plumbing wouldn't live in QKeyMapper, and having it around as dead code doesn't help, so remove it for now, and track the work to implement it in QTBUG-27681. Task-number: QTBUG-27681 Change-Id: I480590550f3bc741b829fb30aa85393b07d5c16f Reviewed-by: Liang Qi <liang.qi@qt.io>
* Remove QKeyMapperPrivateTor Arne Vestbø2023-09-303-38/+3
| | | | | | | | | | | | | | | | | | | There is no point in maintaining the keyboardInputLocale and keyboardInputDirection in the QKeyMapperPrivate, as these things are handled by QInputContext nowadays. The values were never updated either, so the base class implementation of QPlatformInputContext referring to them was confusing. With those gone, we can remove the entire class. Subclasses of QPlatformInputContext typically only override locale(), so we now base the input language direction on the current locale(), giving dynamic updates of the direction as well (without the signal, but this will be fixed in a follow up patch). Change-Id: I16ae4097eadadd278e60edea3c1101ab90ed7444 Reviewed-by: Liang Qi <liang.qi@qt.io>
* Avoid extending dirty region in beginPaintTor Arne Vestbø2023-09-222-3/+10
| | | | | | | | | | | | | | | | | | | | | | When the raster window is resized, we need to resize the backingstore, and make sure we repaint the entire window. We defer the backingstore resize to beginPaint, in case multiple resize events come in before we have a chance to paint, but we can't defer the invalidation of the paint device window, because QPaintDeviceWindowPrivate::paint() has already subtracted the paint region from its dirty region at this point. Invalidating yet again will result in the dirty region of window not clearing fully until after the final resize, and when that happens we will also repaint the window with the wrong dirty region, based on the window's original size. My moving the window invalidation to the resize event, while keeping the deferred backingstore resize we avoid this problem. Pick-to: 6.5 6.6 Change-Id: I44662778f5b1bcd259b20ca86124e6487561ef4f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QKeyMapper: Remove indirection via QKeyMapperPrivate for possibleKeysTor Arne Vestbø2023-09-222-16/+9
| | | | | Change-Id: I1988ac60689b3e6f4b29e38d1167d2b998702c09 Reviewed-by: Liang Qi <liang.qi@qt.io>
* QKeyMapper: Merge default implementation of possibleKeys into call siteTor Arne Vestbø2023-09-221-11/+5
| | | | | | | Task-number: QTBUG-116873 Change-Id: I9091f4a9d465fb928afcabce0536fcd2d03b7f82 Reviewed-by: Andrey Butirsky <butirsky@gmail.com> Reviewed-by: Liang Qi <liang.qi@qt.io>
* Remove QShortcutMap::matches() and use QKeySequence::matches() insteadTor Arne Vestbø2023-09-212-37/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The custom matching function was added in 4d4857027db3 with the rationale that people were mixing up Key_hyphen and Key_Minus all the time, and tried to solve it by treating the two as one and the same in the match function. Unfortunately this doesn't work in practice, as when a keyboard event comes in we resolve a set of possible key sequences from that, and then look those up in the list of sorted shortcut sequences. That lookup is just a binary search, and does not take into account the added logic of the custom matching function. So the binary search will fail to find the matching key sequence, and as a result we never get a chance to call matches() with a potentially malleable key sequence (for example Qt::Key_Minus when the shortcut is Qt::Key_hyphen or vice versa). The only case we do hit the matches function is if we by chance happen to land the binary search iterator on the "unmatched" shortcut, e.g. Qt::Key_hyphen, but this relies on there not being any other shortcuts that sort between Qt::Key_Minus and Qt::Key_hyphen. Task-number: QTBUG-116873 Change-Id: Iaa90991911f32276e29e37e8c7ae87643898bfc9 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QShortcutMap: Rename variables to clarify their useTor Arne Vestbø2023-09-211-52/+53
| | | | | | | | | | | The state machinery of QShortcutMap is complicated enough as it is, so let's use better variable names. In particular, let's distinguish the registered shortcuts (QShortcutEntries), from the candidate QKeySequence sequences that we compute based on the incoming events. Task-number: QTBUG-116873 Change-Id: I9bd59097e786ecfb9d241c2eb7b871a4bba9b44f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QShortcutMap::find: Use plain for-loop instead of do-whileTor Arne Vestbø2023-09-201-19/+21
| | | | | | | | | | | | | | | | The logic was a bit convoluted, using a do-while loop when the base premise still was that we needed a valid iterator, and hiding the check of a QKeySequence::NoMatch to break out of the loop far from the match() that produced it. The tempRes (now match) variable no longer has to live outside the loop, and the oneKSResult variable has been renamed to clarify its use. Task-number: QTBUG-116873 Change-Id: I730e768eae2e9a653bf4e28ceece2fe7277ef45d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Andrey Butirsky <butirsky@gmail.com>
* Improve QShortcutMap debug loggingTor Arne Vestbø2023-09-202-5/+7
| | | | | | | Task-number: QTBUG-116873 Change-Id: I6a2b8c25d3da8c9cbcaeb0979b4be85267ba7856 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Andrey Butirsky <butirsky@gmail.com>
* QWindow: bail out early on resize() if size has not changedVladimir Belyavsky2023-09-151-9/+10
| | | | | | | | | | | | On some platforms, like Windows and Linux, calling resize() may unexpectedly reset window state even when the actual size has not changed. So, bail out early on QWindow::resize() if new size is the same. Task-number: QTBUG-115699 Change-Id: I64ad611044008964b5201951a50f3866e2108b49 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add Python-specific note to QOpenGLContext::aboutToBeDestroyed() documentationFriedemann Kleint2023-09-151-0/+5
| | | | | | | | | | The signal is not received when emitted from the destructor. Pick-to: 6.6 6.5 Fixes: PYSIDE-2460 Change-Id: Ic2273c5b9ef1f53bd58615b6982016e646aee326 Reviewed-by: Adrian Herrmann <adrian.herrmann@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* GUI: give more warning when can't load xcb since 6.5.0Liang Qi2023-09-141-0/+4
| | | | | | | | | | | normally because new depedency of xcb-cursor0 or libxcb-cursor0 is missing. Pick-to: 6.6 6.5 Task-number: QTBUG-108796 Change-Id: I040e9c0932bbf1f9026b365ded462c7373b219b5 Reviewed-by: Eike Ziller <eike.ziller@qt.io> Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Update version for QPalette::accent API in documentationSanthosh Kumar2023-09-131-0/+1
| | | | | | | | Follow up patch to 3c391c159ce0e29a9a654edee45bd64bcde6ccd2. Pick-to: 6.6 Change-Id: I23235ae8516a53cf09c00b0daedc054df2f0cfa8 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Update documentation for QPalette::accent APISanthosh Kumar2023-09-121-0/+8
| | | | | | | | | | | | The documentation for QPalette::accent had been missed and its updated as part of this patchset. Amends patchset 17c589df94a2245ee92d45839c2cba73566d7310. Fixes: QTBUG-116930 Pick-to: 6.6 Change-Id: Iaa53e15dbecaa3c741e2db013c96b4424be39e91 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QWindow: avoid extra window resize on changing min/max sizesVladimir Belyavsky2023-09-121-1/+4
| | | | | | | | | | | | | Amends e7477e8934ab38722f5589914d08b3f15e870109. Do not call QWindow::resize() on changing min/max sizes if bounded window size has not changed. Otherwise it may unexpectedly reset window's state on some platforms, like Windows and Linux. Fixes: QTBUG-115699 Pick-to: 6.5 6.6 Change-Id: I217ca3fd854a1f41d6df312e3258734d1d3bce45 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* gui: use const methods moreAnton Kudryavtsev2023-09-092-3/+3
| | | | | | | to avoid implicit detach Change-Id: I2c7ae56e0866941e0f0b040129bfc40a9a961f3c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QWindow: Fix error for unused captureMårten Nordheim2023-09-081-0/+2
| | | | | | | | Amends 89ce65c2d01e77c1cf49bb8579f63b60480e0186 Pick-to: 6.6 Change-Id: Ifddf6b2e849929137d1db8f777a7cb9fa3cd2038 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Change MaxKeyCount type from enum to static constexpr intTomasz Kozlowski2023-09-071-1/+1
| | | | | | | | | | The change was needed because std::fill_n(), which takes it, does not handle enum type on VxWorks. As it was anonymous with only one member, it could be changed to static constexpr int. Task-number: QTBUG-115777 Change-Id: I7cb4d267ad21f6b963d851e30bc91042fbf5c15a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Always run screen change side effectsMorten Sørvig2023-09-072-11/+13
| | | | | | | | | | | | | | | | processWindowScreenChangedEvent() returns early if the screen for the (top-level) window has already been updated, for instance by a call to handleScreenRemoved(). This was preventing us from updating the DPR and window geometry. Move the code a slot connected to QWindow::screenChange, which gets emitted for all windows (also child windows), whenever the screen changes. Pick-to: 6.6 Fixes: QTBUG-116232 Change-Id: I44701fd001ab1fd54efe9c8451c6a58cfc0b285f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Note that QPalette::ColorRole must be kept in sync with QQuickColorGroupMitch Curtis2023-09-011-0/+1
| | | | | | | | | | | Without adding the corresponding properties, they will not be available in QML. Task-number: QTBUG-116106 Pick-to: 6.6 Change-Id: I233e456ced585b9274a1724cc550bc2959757104 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QGuiApplication: Report default platform name before initializationPasi Petäjäjärvi2023-08-251-2/+14
| | | | | | | | | | | | | | | Calling this function before we had a QGuiApplication instance, would return an empty string, even if QT_QPA_DEFAULT_PLATFORM_NAME was defined at compile time. We now return the default platform name [ChangeLog][QtGui][QGuiApplication] QGuiApplication::platformName now reports the default platform name if QGuiApplication hasn't been instantiated yet. It used to return an empty string. Pick-to: 6.6 6.5 Change-Id: Iffe7cde8943ed2d186bc494d0920b9cf79389dd0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Reduce nesting in processWindowScreenChangedEvent()Morten Sørvig2023-08-241-18/+20
| | | | | | | | | Replace if-block with early return on null QWindow. Pick-to: 6.6 Task-number: QTBUG-116232 Change-Id: Iaf402edfd9b03734b64fdf707834fa92c827a1dc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Doc: Delete links to removed examplesAndreas Eliasson2023-08-181-1/+1
| | | | | | | | | | The examples have been removed as part of the examples revamp project. This patch resolves a number of qdoc warnings. Pick-to: 6.6 6.5 Change-Id: Ie3d2f5637136c631d7e9f7a8ffd93baea52f77d8 Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QMessageBox: leave the Option's underlying_type as the default, intMarc Mutz2023-08-181-1/+3
| | | | | | | | | | | | | | | QFlags<Option> will anyway store the value in an `int`, so we gain nothing from choosing quint8 as the fixed type, except artificially limiting the number of possible future options to eight. Found in API-review. As a drive-by, put options one per line and add a trailing comma where possible. Pick-to: 6.6 Change-Id: I0ed588ea6c7912e50705af89c47e2cf7e2ee23a0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Rename accent color in QPaletteSanthosh Kumar2023-08-183-15/+15
| | | | | | | | | | Accent color role has been renamed according to name rule of other color roles in QPalette. Fixes: QTBUG-116107 Pick-to: 6.6 Change-Id: I70ac98a1e97afbdc7ea5f8d79f808c307e170712 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Don't keep around old dirty region when entire window is invalidatedTor Arne Vestbø2023-08-071-1/+1
| | | | | | | | | | | | | | | | QPaintDeviceWindowPrivate::markWindowAsDirty() is used to signal that the entire window needs repaint, for example when the window is being resized. If multiple resize events come in before we have a chance to redraw the window, we'll end up redrawing the window based on the window's current size and exposed region, as we should, but we'll still have a dirty region, because we didn't redraw the window at any of its old (larger) sizes. Resetting the dirty region instead of appending to it should be enough. Pick-to: 6.6 6.5 Change-Id: I37443cc1044779f847348a2303a6cebc1a8f3bcb Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QMutableEventPoint::update(): update the touchpoint uniqueId tooShawn Rutledge2023-08-041-0/+1
| | | | | | | | | | Most touch events don't have uniqueIds, but it happens with TUIO fiducial objects. Fixes: QTBUG-115758 Change-Id: Ibacce255898ce63090bc5b888c12242838603dd5 Pick-to: 6.5 6.6 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-13 02:41:12 +0000