summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/windows/qwindowswindow.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "WindowsQPA: Make custom titlebar a child window"Jani Heikkinen12 days1-50/+149
| | | | | | | | | | This reverts commit 295933aadce1222511aa33bd1c68c302ca0a0a61. Reason for revert: QTBUG-137779 Change-Id: I70a7d9e095c442e078bf012dd52395b05bf5f04c Reviewed-by: Oliver Wolff <[email protected]> Reviewed-by: Axel Spoerl <[email protected]>
* WindowsQPA: Make custom titlebar a child windowWladimir Leuschner2025-06-131-149/+50
| | | | | | | | | | | | | | | | | | The current approach for custom titlebar uses an overlay of a frameless popup window at the position of the titlebar area. This involves synchronizing the window state, position and size of the popup window with the original window. Also, the drawing of rounded edges needs to be done manually with the old approach. This patch adds the titlebar as a real child to the original window, so that the window manager takes care of the synchronization and clipping process. Fixes: QTBUG-135643 Fixes: QTBUG-133943 Fixes: QTBUG-133946 Pick-to: 6.10 6.9 Change-Id: I1770580a1c306074f41a7ff64c1d525c93918480 Reviewed-by: Oliver Wolff <[email protected]>
* QPA/Windows: Fix QPainter warnings when animations are disabledChristian Ehrlicher2025-06-101-7/+11
| | | | | | | | | | | | | Don't draw on a QImage with a size of 0/0. This amends 5feefd30734cd12753956819fc7c152be07c24cd Pick-to: 6.10 6.9 6.9.1 Fixes: QTBUG-135844 Task-number: QTBUG-127634 Change-Id: Ib57cdccfabe67454984f3229f9d7ad02dd0d9992 Reviewed-by: Błażej Szczygieł <[email protected]> Reviewed-by: Wladimir Leuschner <[email protected]>
* Use WS_EX_NOACTIVATE to prevent window from getting focusedMorteza Jamshidi2025-05-301-0/+3
| | | | | | | | | | | | | | | | | | | On top of handling ActivateWindowEvent,MouseActivateWindowEvent and PointerActivateWindowEvent events and returning MA_NOACTIVATE we can also set the window extended style to prevent windows from stealing focus in special cases. Also on top all those mentioned events, when the window is requested to get keyboard focus, it should check if the window accepts focus or not. If it does not, then it should inform the underlying system that the window does not accept the focusIn event. [ChangeLog][Windows] Windows with flag Qt::WindowDoesNotAcceptFocus no longer have a taskbar entry. Pick-to: 6.9 Fixes: QTBUG-131714 Change-Id: I79f767b1622449ba05b41f8b80bf390d8cecfff8 Reviewed-by: Oliver Wolff <[email protected]> Reviewed-by: Zhao Yuhang <[email protected]>
* Revert "Windows QPA: Remove usage of deprecated DwmEnableBlurBehindWindow"Wladimir Leuschner2025-05-261-0/+25
| | | | | | | | | This reverts commit b07876105788d519a3bb04a353eaa5ffa6269253. Reason for revert: Introduced regression QTBUG-136098 Change-Id: Id1f4d7a485659c4150f6750866c2f702fcdc1bf6 Reviewed-by: Oliver Wolff <[email protected]>
* Windows: Update layered state on creation instead of backingstore flushTor Arne Vestbø2025-05-181-9/+4
| | | | | | | | | | | | | | | | | | The WS_EX_LAYERED state of a window can be determined on creation, and the logic to do so should be centralized to QWindowsWindow::setWindowLayered, so that we don't have divergence. This fixes an issue where child windows would only support transparency if they had Qt::FramelessWindowHint set, as the QWindowBackingStore had a different idea about when to enable WS_EX_LAYERED than QWindowsWindow. Task-number: QTBUG-122590 Task-number: QTBUG-135859 Pick-to: 6.9 6.8 Change-Id: I453967a5a2ce8974cdd1dbf6e36327e97384c33d Reviewed-by: Oliver Wolff <[email protected]> Reviewed-by: Zhao Yuhang <[email protected]> Reviewed-by: Pavel Dubsky <[email protected]>
* Windows: Detect lack of WS_CLIPCHILDREN when adding child windowsTor Arne Vestbø2025-05-151-1/+19
| | | | | | | | | | | | | The lack of WS_CLIPCHILDREN will cause drawing artifacts, so ensure we have WS_CLIPCHILDREN in our native window manual tests, and warn if users inadvertently end up reparenting windows into a HWND that doesn't have WS_CLIPCHILDREN set. Change-Id: Ic4dac83882167562599d63f46232071c8c21b617 Reviewed-by: Zhao Yuhang <[email protected]> Reviewed-by: Wladimir Leuschner <[email protected]> Reviewed-by: Oliver Wolff <[email protected]> Reviewed-by: Pavel Dubsky <[email protected]>
* WindowsQPA: Make custom titlebar respect swapped mouse buttonsWladimir Leuschner2025-05-141-7/+13
| | | | | | | | | | | | | | | | Custom titlebar input handling is done on WM_NCHITTEST, which is handled at the WinAPI level. The WinAPI does not take into account the swapped mouse buttons when querying the state of VK_LEFTBUTTON and VK_RIGHTBUTTON with GetAsyncKeyState, so this behavior has to be implemented manually. In case of swapped mouse buttons, GetSystemMetrics(SM_SWAPBUTTON) will return true. This patch inverses the meaning of Right and Left buttons in case GetSystemMetrics(SM_SWAPBUTTON) returns true. Pick-to: 6.9 Change-Id: Ie46e130dc0bb49de318c8d04a3cc426f7a346b5b Reviewed-by: Tor Arne Vestbø <[email protected]> Reviewed-by: Zhao Yuhang <[email protected]>
* WindowsQPA: Add default icon to custom titlebarWladimir Leuschner2025-03-171-8/+13
| | | | | | | | | | | In case that no application icon was provided, use the IDI_APPLICATION icon when Qt::WindowTitleHint was provided. Fixes: QTBUG-133941 Pick-to: 6.9 Change-Id: Ifb479a7056e0841215d525c2346938bda31fc1c6 Reviewed-by: Tor Arne Vestbø <[email protected]> Reviewed-by: Oliver Wolff <[email protected]>
* WindowsQPA: Adjust close button and hover color for custom titlebarWladimir Leuschner2025-03-171-3/+6
| | | | | | | | | | | | Adjust toe color of the close button to match the native color. Adjust the hover text color for the close in light mode to match the native behavior. Fixes: QTBUG-133945 Pick-to: 6.9 Change-Id: I2c9fafba9fee65f45f3878168b67b0d0a4b2a54c Reviewed-by: Tor Arne Vestbø <[email protected]> Reviewed-by: Oliver Wolff <[email protected]>
* WindowsQPA: Add default window title to custom titlebarWladimir Leuschner2025-03-121-2/+3
| | | | | | | | | | In case that no window title was provided use the QCoreApplication::applicationName when Qt::WindowTitleHint was provided. Fixes: QTBUG-133942 Pick-to: 6.9 Change-Id: Ieeff0ba97bd996225c6f83f691fc1c149e3d7172 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Revert "Windows: Check for bitmask instead for equality for initial window ↵Wladimir Leuschner2025-03-031-4/+9
| | | | | | | | | | | | flags" This reverts commit 369be485101c856c626a85f77ea087603dcf8b6c. Reason for revert: This breaks the customize window hints on Windows. Fixes: QTBUG-133940 Change-Id: Ib553c3f3742a14e0487cda27d057a4f4d50f76e2 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Windows: Check for bitmask instead for equality for initial window flagsWladimir Leuschner2025-02-181-9/+4
| | | | | | | | | | fixTopLevelWindowFlags uses a equality comparison for the initial window flags fixup. In case window flags are set before creation, this equality will fail and no initial window flag fixup will happen. This patch changes the equality comparison with a test for bitmasks. Change-Id: I5a18f37376af5cc72f5ee7a3365970ca7fd51b66 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Windows: Fix title bar artifact for frameless windows after restoringMorteza Jamshidi2025-02-181-0/+12
| | | | | | | | If windows is frameless we don't let windows os handle WM_NCACTIVATE event. Fixes: QTBUG-127116 Change-Id: I90f6a394018d0b275c77d319f0dc6fe93707694e Reviewed-by: Richard Moe Gustavsen <[email protected]>
* Replace QBoolBlocker with QScopedValueRoolbackThiago Macieira2025-01-271-1/+1
| | | | | | | | | | | | | It was pre-Qt 4.5 (so pre-C++11), while QScopedValueRollback is 4.8. Both are still old, but with Qt 6 and C++17, we can use CTAD. QScopedValueRollback requires a value change to be explicit, which is less surprising. The uses outside of qtbase have also been fixed. Change-Id: Ia930b1a2ed1e465a826ffffd179c1909e16583db Reviewed-by: Marc Mutz <[email protected]>
* Show window without activating if WindowDoesNotAcceptFocus flag is setMorteza Jamshidi2025-01-241-1/+5
| | | | | | | | | Added an extra condition to only show the window (without activation) if Qt::WindowDoesNotAcceptFocus flag is set. (Mostly from qml) Fixes: QTBUG-130912 Change-Id: I6b7a9cd03d726315b8531600c6a8b33436a3348b Reviewed-by: Tor Arne Vestbø <[email protected]>
* WindowsQPA: Draw custom titlebar with QPainterWladimir Leuschner2024-12-171-105/+128
| | | | | | | | | | | - Draw custom titlebars that are requested by setting the Qt::ExpandedClientAreaHint with QPainter instead of GdiPlus. - Draw the application icon, in case it was set, for the custom titlebar - Add DPI awareness to the custom titlebar Pick-to: 6.9 Change-Id: I276e7d8948e5a436f1835d96b59756b7237f63d2 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Windows: Fix title bar size calculationYuhang Zhao2024-12-171-7/+17
| | | | | | | | | The title bar calculation is terribly wrong and was missed during review. Pick-to: 6.9 Change-Id: I0c7a860e747465e6a5e4d8aa5415a9701cf170fd Reviewed-by: Oliver Wolff <[email protected]>
* Windows: Add a missing WINAPI for a callback functionMartin Storsjö2024-11-281-1/+1
| | | | | | | | | | | | | | | | This fixes compilation for i686 after 5feefd30734cd12753956819fc7c152be07c24cd, fixing compilation errors like these: qtbase/src/plugins/platforms/windows/qwindowswindow.cpp:901:69: error: no matching member function for call to 'registerWindowClass' 901 | const QString windowTitlebarName = QWindowsContext::instance()->registerWindowClass(QStringLiteral("_q_titlebar"), WndProcTitleBar, CS_VREDRAW|CS_HREDRAW, nullptr, false); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ qtbase/src/plugins/platforms/windows/qwindowscontext.h:77:13: note: candidate function not viable: no known conversion from 'LRESULT (HWND, UINT, WPARAM, LPARAM)' (aka 'long (HWND__ *, unsigned int, unsigned int, long)') to 'WNDPROC' (aka 'long (*)(HWND__ *, unsigned int, unsigned int, long) __attribute__((stdcall))') for 2nd argument 77 | QString registerWindowClass(QString cname, WNDPROC proc, | ^ ~~~~~~~~~~~~ Change-Id: I9eb2d3dc0626b8606d4b49cf82fba34d6a4b2942 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Windows: Implement Qt::ExpandedClientAreaHint/NoTitleBarBackgroundHintWladimir Leuschner2024-11-271-7/+418
| | | | | | | | | | | | | | Windows with the Qt::ExpandedClientAreaHint set extends the client area to include the native titlebar area, while keeping the functionality of systemmenu, resizing and aero snap. Also this flag indicates, that Qt is drawing a title bar as an overlay over the extended client area. Additionally setting Qt::NoTitleBarBackgroundHint will make the titlebar background transparent, so that the widgets below are visible and interactible. Task-number: QTBUG-127634 Change-Id: Ib267d199f42a4ee90e7a51fe60a41295b82031d6 Reviewed-by: Tor Arne Vestbø <[email protected]>
* platforms/windows: fix deprecated C++ 20 implicit capture of this in [=]Ahmad Samir2024-11-111-1/+1
| | | | | | | | | | | | | | With MinGW, GCC and Clang `[=, this]` is acceptable in C++20 mode, but MSVC on the CI still builds with C++17. So use `[&]`, the other two variables used inside the lambda are (const) built-in types, taking by reference is the same as taking by copy. Amends a90d99d8da9b2be2e6b8e981cd9dabfb1641e985. Pick-to: 6.8 Change-Id: Ib1c746ccf1c02b2ee3891eca5bddd7e47f559dc5 Reviewed-by: Marc Mutz <[email protected]> Reviewed-by: Oliver Wolff <[email protected]>
* Windows QPA: Make frameless window respect WORKAREAWladimir Leuschner2024-11-071-2/+18
| | | | | | | | | | | | | Windows that have only set the WS_POPUP style do not take the WORKAREA into account and maximize to fullscreen geometry. This patch maximizes a WS_POPUP window to the size of the current working area, which can be smaller than the screen geometry. Fixes: QTBUG-129791 Fixes: QTBUG-130865 Pick-to: 6.8 6.5 Change-Id: I4c5beb0cd69c7ea4c585785a579a9d66bab12cc6 Reviewed-by: Oliver Wolff <[email protected]>
* Revert "Windows QPA: improve Qt::FramlessWindowHint windows"Wladimir Leuschner2024-11-051-80/+32
| | | | | | | | | | This reverts commit 1a6ab689d5858e5997c989ce6c3574fb591438b0. Reason for revert: Regression: FrameLessWindows have borders now when they should not. Change-Id: Ia975acf6f63a44e2ff3362aa573b1d9b11f7edd9 Reviewed-by: Tor Arne Vestbø <[email protected]> Reviewed-by: Oliver Wolff <[email protected]>
* Windows QPA: improve Qt::FramlessWindowHint windowsTimothée Keller2024-10-221-32/+80
| | | | | | | | | | | | | | | | | | Currently, Qt::FramelessWindowHint windows lose functionalities that we might want them to keep. This patch attempts to address these by giving the frameless windows the following features: - Border-resizable: it is now possible to resize them by hovering over the edges of the (invisible) border. - Aero snap: While this patch does not enable dragging by clicking on non client areas, shortcuts like Win key + arrow keys let the user snap the windows as expected. - Animations/Shadows: minimizing/maximizing windows now has the typical animations, and the windows also have shadows. Change-Id: Icd7b671a6ac3dc300ba78378897b5dcae2432f76 Reviewed-by: Tor Arne Vestbø <[email protected]> Reviewed-by: Oliver Wolff <[email protected]>
* d3d: Drive window updates from a vblank watcher threadLaszlo Agocs2024-10-151-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Have dedicated threads that just do IDXGIOutput::WaitForVBlank() and fire off notifications. I.e., create something conceptually similar to macOS' CVDisplayLink. Then hook this up to QWindow::requestUpdate(). For windows that are not D3D and not used with an active QRhi, or when the used D3D adapter is WARP that reports no DXGI outputs, this has no effect, and everything works like before, with the standard requestUpdate behavior of using a 5 ms (or less) timer. For development purposes one can always disable this by setting the environment variable QT_D3D_NO_VBLANK_THREAD to a non-zero value. To have some debug output, enable the category qt.qpa.screen.updates. Multiple refresh rates are supported by using dedicated a notifier thread per output. This way we do not bake in assumptions about the composition and presentation behavior, which is good since it is reported to have changed around Win 11 23H2 (DWM not anymore limiting to the primary display's refresh rate). E.g., just having a single thread ticking based on the primary screen would be quite wrong. The result is a very visibly reduced display lag e.g. with the classic test case of dragging an item with the mouse around in a Qt Quick scene, less time spent on throttling to the presentation rate (and more time in the event loop, presumably), and, for some reason, a noticeable reduction in the reported CPU load as well. This complements the 6.8 changes that added a blocking wait on the frame latency waitable object (with max latency set to 2) in beginFrame(). Those changes provided some improvements for the lag-when-dragging case in particular, effectively bringing the out of the box Qt 6 experience with D3D on par with the Qt 5 results with OpenGL (results vary with diferent vendors; all testing here has been done with NVIDIA graphics). Whereas this more complex approach on top provides further improvements, which were not possible to achieve before with any configuration of 3D APIs or settings. [ChangeLog][Windows] By default, windows that get rendered to with QRhi using either the D3D11 or D3D12 backend base their update request deliveries on notifications from dedicated vblank waiting threads. This affects both direct users of QWindow::requestUpdate() and also Qt Quick, since QQuickWindow uses the same mechanism internally. This is expected to provide smoother presentation, in particular a reduced display - mouse cursor lag when dragging items in a Qt Quick scene for example, and potentially reduced CPU load. Note that this is not applicable when using an adapter such as WARP. For development and testing purposes, it is possible to request the old behavior by setting the environment variable QT_D3D_NO_VBLANK_THREAD to a non-zero value. Task-number: QTBUG-127267 Change-Id: I6e35e776f495bc34cf164164da8ce7f9e74f45b6 Reviewed-by: Oliver Wolff <[email protected]>
* QWindowsWindow: Refactor corrections related to task bar on top / leftAxel Spoerl2024-10-101-20/+60
| | | | | | | | | | | | | | | | | | | | | | | 33874a9424cd03c21ca9986a39c383b3689f03d2 corrected a size-contrained window's position when maximized. Restoring such a window's size moved the window downwards as well, if the task bar was on top. With the task bar on the left, such maximizing the window caused parts of it to be off screen to the right. These bugs affect only Windows 10, because Windows 11 only allows the task bar to be at the bottom. Factor out all corrections to QWindowsWindow::correctWindowPlacement(). Correct placement when restoring size of a maximized, size-constrained window. Correct width of a height-constrained, maximized window. Correct height of a width-constrained, maximized window. Change-Id: I9a1e0cf4708e8c579595fdbdc7f16b927be53b05 Done-with: Johannes Grunenberg <[email protected]> Fixes: QTBUG-129405 Fixes: QTBUG-129679 Task-number: QTBUG-123752 Pick-to: 6.8 6.5 Reviewed-by: Oliver Wolff <[email protected]>
* Windows: Set window style in correct order when reparenting foreign windowsTor Arne Vestbø2024-09-171-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | The SetParent() documentation notes that when making a window a child window the window style should be set before calling SetParent(), while the opposite order should be used when making a window top level. We were exclusively doing the latter, which resulted in child windows getting activated and focused as part of the reparenting. Being the active window was resulting in the child window receiving WM_CLOSE and being destroyed if the user pressed Alt+F4, which was very surprising. The child window can still be focused later on, via e.g. an explicit call to SetFocus(), so it can receive keyboard input. The QWindowsWindow::setParent_sys() logic, used for non-foreign windows has the same fundamental issue with not respecting the order of the style update, but the interactions with the drop site logic makes it harder to update in similar fashion as this patch does for QWindowsForeignWindow. Pick-to: 6.8 6.8.0 Change-Id: Id88f5981daaf121a39aba9319d02aebefb6aa07b Reviewed-by: Jøger Hansegård <[email protected]> Reviewed-by: Oliver Wolff <[email protected]>
* XCB/Windows: Decouple foreign window from QWindow parent on destroyTor Arne Vestbø2024-09-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Qt's foreign windows do not take (full) ownership of the native handle, so our platform window implementations take care to not fully destroy the native handle in their destructors. But if the foreign window had a QWindow parent at the time of destruction, and we fail to decouple the native handle from its native handle parent, the destruction of the QWindow parent may bring down the foreign window native handle as well, as part of deleting the parent QWindow's native handle. We take care to selectively do this decoupling on macOS, iOS, and Android, but were failing to do so on XCB and Windows. This has now been corrected, which allows us to remove the workaround in QWindow, which was also in the wrong place (before setVisible(false) on the foreign window child). Note that we do not unconditionally reparent the foreign window, as it might be a foreign window used for containing other QWindows, in which case we don't want to mess with the native view hierarchy. Pick-to: 6.8 Change-Id: Ic526ca63fbf72dae5013ae9e44cb5cddf61c944b Reviewed-by: Liang Qi <[email protected]>
* QWindowsWindow: Work around offset bug in GetWindowPlacement()Axel Spoerl2024-08-221-0/+22
| | | | | | | | | | | | | | | | | | | GetWindowPlacement() stores wrong positions in the &WINDOWPLACEMENT argument's ptMaxPosition member on Windows 10. (1) Each time a fixed height window is maximized, ptMaxPosition moves - down by the task bar's height, if the task bar is on top - right by the task bar's width, if the task bar is on the left (2) The frame margins' left offset (typically -8) is not respected. On Windows 10, set ptMaxPosition to {0, 0} adjusted by the frame margins' left offset. Fixes: QTBUG-123752 Pick-to: 6.8 6.7 6.5 6.2 Change-Id: I8bbd63d93a7648921b703ff6f3e09c4cf2999be2 Reviewed-by: Oliver Wolff <[email protected]>
* a11y: Report actual platform window name on WindowsMichael Weghorn2024-08-221-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | Remember the value set for the window name in QWindowsWindow::setWindowTitle. Override QPlatformWindow::windowTitle introduced in a previous commit for QWindowsWindow and let it return the formatted window name as it was actually set. With this in place, the NVDA screen reader on Windows now announces "MyApp, window" as expected when the sample app from QTBUG-127563 receives focus, and the accessible name that is now matching the displayed window title can also be seen in NVDA's interactive Python console: >>> focus.name 'MyApp' Fixes: QTBUG-127563 Change-Id: Ifca165d6c302199d771ce0805c4d2d91047ca31c Reviewed-by: Oliver Wolff <[email protected]>
* Revert "Update window state in QWindowsWindow and QXcbWindow geometry setters"Axel Spoerl2024-07-161-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 99c8ffb9f259760e45618f0988bbd79237d6d291. It fixed QTBUG-104201, which in essence pointed out a state mismatch between widgets and platform windows on Linux (X11 and wayland). Mismatches occurred in the margins between calls to QWidget and async screen rendering: While the widget layer reported the expected size, the platform layer did so only after the rendering thread had finished. As mentioned in the comments of QTBUG-104201, the state mismatch is predictable, temporary and consistent. By bridging the time gab, an async operation was made to look synchronous. That gave more comfort to application developers. By oversight, it broke code that relied on the platform window state reflecting physical rendering. This has caused QTBUG-126479 as a regression. Both purposes can't be served at the same time: The platform window state either reflects rendering, or the expected state. It's therefore justified to revert. Reason for revert: <Causes QTBUG-126479> Pick-to: 6.8 6.7 6.5 Fixes: QTBUG-126479 Task-number: QTBUG-104201 Change-Id: I22380a6a463822a1cb4be90a44d2775954c7ca82 Reviewed-by: Liang Qi <[email protected]>
* Windows QPA: Remove usage of deprecated DwmEnableBlurBehindWindowWladimir Leuschner2024-07-111-31/+0
| | | | | | | DwmEnableBlurBehindWindow was deprecated with Windows 8 and has no effect in subsequent versions of Windows. Change-Id: I0c8390d07f88195649fe9f240b3062cc9824c8b6 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Windows QPA: Prevent restoreGeometry from showing hidden windowsTimothée Keller2024-05-271-0/+5
| | | | | | | | | | | | | | When we use GetWindowPlacement, the showCmd parameter will NOT be SW_HIDE, even if the window is hidden. To prevent showing a hidden window with SetWindowPlacement, change showCmd if the window is currently hidden. Amends 21e411687428d05655b8db2634466384fa35cc03 Fixes: QTBUG-120415 Pick-to: 6.7 Change-Id: Ib7de369a6d1a530fdeb5ff930097ae06e25761f3 Reviewed-by: Oliver Wolff <[email protected]> Reviewed-by: Zhao Yuhang <[email protected]>
* Windows: only consider actual palette when selecting frame appearanceVolker Hilsheimer2024-05-221-6/+0
| | | | | | | | | | | | Even if dark mode has been requested by the application explicitly, a style, like the Vista style, might polish the palette to be light. In that case, the frame should be light as well. Amends 95d4e6bababfeb36fa8a355a8487b64eb3ffb587. Task-number: QTBUG-124490 Change-Id: I7ddb0a80a5f043e98cf184537bffe75e917c3d38 Reviewed-by: Tor Arne Vestbø <[email protected]>
* ColorScheme: make QStyleHints::colorScheme writable for applicationsVolker Hilsheimer2024-05-101-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Applications can request the color scheme to be either explicitly light or dark, or to follow the system default by setting the scheme to Qt::ColorScheme::Unknown. Setting the color scheme will make the request to the QPlatformTheme implementation, which can then use the appropriate implementation to set the application's appearance so that both palette and window decoration follow the requested color scheme. This should trigger theme change and palette change events. A change to the effective scheme should then call back into QStyleHintsPrivate::updateColorScheme, which will emit the changed signal for the property. Implement this for macOS (Cocoa), iOS, Android, and Windows. On macOS, we have to use deprecated AppKit APIs; the replacements for those APIs are not suitable for this use case. On iOS, the setting is for each UIWindow, which we can update or initialize based on an explicitly requested scheme. On Android we can piggy-back on the logic added when dark theme support was introduced in b4a9bb1f6a40e6d504c1f48f0d9ea2b70ab1a9f0. On Windows, we have to fake a dark palette if the dark scheme is requested on a light system, as there is no API to read a dark palette. However, we also have to ignore any application preference if a high- contrast accessibility theme is selected by the user (we report the color scheme as unknown; there are both light and dark high-contrast themes), and read the system palette using the GetSysColor API, which is used for light mode. And we need to initialize windows with the correct frame if the application explicitly overrides the system color scheme. Add an auto-test to the QApplication test, as that gives us the most coverage to confirm that QStyleHints emits the changed signal, and that Theme- and PaletteChange events are received by the toplevel widget when the color scheme actually changes. This test has to be skipped on platforms where we cannot set the color scheme programmatically. Add the option to explicitly select the color scheme to the widget gallery example, and default it to dark mode. Fixes: QTBUG-124490 Change-Id: I7302993c0121284bf9d3b72e3149c6abbe6bd261 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Windows: simplify setting the dark borderVolker Hilsheimer2024-05-031-13/+0
| | | | | | | | | | | | | | | A round trip through querying the window attribute to avoid a call to the setter is overkill, we can assume that the setter won't do anything if the value of the attribute doesn't change. Also, don't check whether QWindowsIntegration::darkModeHandling is overridden before calling setDarkMode, which checks that flag already. The flag will be very rarely cleared (and we might want to remove support for this obscure mechanism soon). Task-number: QTBUG-124490 Change-Id: I7e027fd53f556200edfd127eaf5f2b97f027528e Reviewed-by: Oliver Wolff <[email protected]>
* ColorScheme: consolidate dark mode handling on Windows into ThemeVolker Hilsheimer2024-04-251-2/+3
| | | | | | | | | | | | | | | Move storage of whether dark mode is set into a static class member of QWindowsTheme, and remove QWindowsContext::isDarkMode; ask the theme instead using the colorScheme() implementation, which will return the stored value. Move the code handling settings changes into QWindowsTheme as well. Task-number: QTBUG-124490 Change-Id: I4795e80b6ab2c94701385dc84771e9ad5578cf32 Reviewed-by: Oliver Wolff <[email protected]> Reviewed-by: Wladimir Leuschner <[email protected]> Reviewed-by: Tor Arne Vestbø <[email protected]>
* QWindow: Persist foreign winId to support destroy/create cyclesTor Arne Vestbø2024-04-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | We used to set a private _q_foreignWinId property on QWindow when creating foreign windows, and this was the mechanism which we then passed the foreign winId to the platform plugin. With c585802e946d97e7d177ea334a162dc7bc286b84 this was removed, since we now were passing the winId through via explicit QPA APIs, and since 0c6911e5cde24c45d6f2c08b6e71064bdd1eccfa removed the ability to explicitly destroy() a foreign window. But when closing a QWindow, we destroy both the window itself, and all its children, including foreign windows. In this case we still want to support recreating the foreign window, for example when the parent window is shown again. To enable this we restore the _q_foreignWinId private property, but keep the limitation of not being able to explicitly destroy a foreign window. Pick-to: 6.7 6.5 Fixes: QTBUG-124160 Change-Id: Ia885ba9f043e64fb21eedd2b4c344679726f1b5c Reviewed-by: Oliver Wolff <[email protected]>
* Windows QPA: Include custom margins in atypical marginsTimothée Keller2024-03-051-5/+6
| | | | | | | | | | | | When calculating atypical margins that are used with ExtendsContentIntoTitleBar, the margins were checked against systemmargins, and then custom margins were added later. Instead, add the custom margins immediately and take them into account during calculations. Pick-to: 6.7 6.6 6.5 Change-Id: I44af663c85b8bdf080d769e3b38431cbe5df64f3 Reviewed-by: David Faure <[email protected]>
* windows: Remove workaround for delayed OpenGL initializationTor Arne Vestbø2024-03-011-22/+0
| | | | | | | | | | We no longer use QSurface::RasterGLSurface for composition, so the window will already be QSurface::OpenGLSurface during WindowCreationData::initialize. Pick-to: 6.7 6.6 6.5 Change-Id: I9b5ea0245ddf4a19d165bde9ad6fd48a98bfca4f Reviewed-by: Laszlo Agocs <[email protected]> Reviewed-by: Oliver Wolff <[email protected]>
* Windows QPA: don't take dpi rounding policy into account when fullscreenTimothée Keller2024-01-161-10/+10
| | | | | | | | | | | With some HighDpiScaleFactorRoundingPolicy, going fullscreen can end up not filling the whole screen. In this case, ignore the rounding (only for the window size, not its content). Fixes: QTBUG-115954 Pick-to: 6.7 6.6 Change-Id: Ie87196358ef28dbe2fcbc180b1740ed9f784b4a0 Reviewed-by: Oliver Wolff <[email protected]>
* Fix Maximized frameless window painting wrong with WS_THICKFRAMEYansheng Zhu2023-12-211-12/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | In Qt versions greater than 6.4.2, when using Qt:FramelessWindowHint and WS_THICKFRAME simultaneously, and handling the WM_NCCALCSIZE message to draw a frameless window, the right and bottom sides may extend beyond the drawable boundaries. This is because in the previous commits, the calculation for margins was skipped for windows with Qt:FramelessWindowHint set. This is correct for non-maximized windows. However, when a window is maximized on Windows, its actual size is slightly larger than the drawable area to avoid users from dragging the border to resize the window. When window was maximized , the code for calculating geometry should remove the margins instead of skipping its calculation. The fixed code determines whether to skip the calculation of margins and frame by checking whether the window is maximized during the calculation [ChangeLog][QPA][Windows] Adding a check for the maximized state of the window during the calculation of margins. Margins calculation will not be skipped for maximized windows. Task-number: QTBUG-120196 Pick-to: 6.7 6.6 6.5 Change-Id: I63c8dbc8f65ff28cc581be261acfd3f675b027c4 Reviewed-by: Oliver Wolff <[email protected]>
* Windows QPA: don't override user-removed marginsTimothée Keller2023-12-181-5/+14
| | | | | | | | | | | When calculating margins, added a check to see if the window rect and the client rect are the same size. If they are, we return early, to avoid overwriting user-defined specific margins. Fixes: QTBUG-117704 Pick-to: 6.7 6.6 6.5 Change-Id: I9947feab4cb900293fb6be6cf09c56268f38d64a Reviewed-by: Oliver Wolff <[email protected]>
* Windows: Improve hidpi style drawing and metricsMorten Sørvig2023-11-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Follow-up change from enabling DPI awareness, which caused some style elements (for instance check boxes) to be rendered incorrectly on non-primary displays, when there is a difference in DPI between displays. Use two approaches to get system metrics and themes: * Use forDpi() API variants and query at 96 DPI for style metrics, that are in device independent pixels. These are metrics which are used for layout calculations. * Get theme metrics at the target display DPI, and scale to device independent pixels when needed. This is used for OpenThemeData(), since this theme is used for drawing as well and needs to be in device pixels. One approach is not used any more: * Get metrics for the main display, and scale by the ratio between the main and target display. Change the theme cache to cache themes per window handle (HWND). This is required since OpenThemeData() returns theme data for a specific DPI, which means we can no longer use a shared cache. Clear the cache on theme change, DPI change, and when the window is destroyed. This handles cache invalidation when the window is moved to a different screen, and also when the DPI for a screen is changed. Move the cache implementation to QWindowsStyleSupport in QtGui, where it can be accessed by both the style and windows platform plugins. Task-number: QTBUG-110681 Change-Id: I5a4ff3a3753762bad8a51d08e51e8013bc7816a1 Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Jøger Hansegård <[email protected]> Reviewed-by: Tor Arne Vestbø <[email protected]>
* Fix margin issue in wizard for windowsSanthosh Kumar2023-10-311-4/+4
| | | | | | | | | | | | | The patch set 8dbc4824895ea9f87d1f6406fe2d22336b6253ed extends support in calculating margins when ExtendsContentIntoTitleBar() is used. But this affects existing QWizard that sets custom margins through Aero style. This is because, the custom margins set by Aero style excludes top margin (titleBarSizeDp()) and excluding it once again cause slicing in the client window area. This patch set fixes it by considering top margin only when system margins is used in windows. Fixes: QTBUG-117428 Pick-to: 6.6 6.5 Change-Id: I6d6eefc691f26474257b58304dac169fba20b5e1 Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Timothée Keller <[email protected]> Reviewed-by: Morten Johan Sørvig <[email protected]>
* Windows QPA: remove SWP_NOCOPYBITS for plain movesTimothée Keller2023-10-171-4/+8
| | | | | | | | | | | | | The SWP_NOCOPYBITS flag helps suppress some jittering during resizes. At the moment this is called even for plain moves with no window resizing. Make sure that the window geometry has changed before applying the SWP_NOCOPYBITS flag Fixes: QTBUG-115992 Pick-to: 6.6 6.5 Change-Id: Ic0cb32d9eb3b557bf2b2ef5b6ba80d34e27c5c19 Reviewed-by: Oliver Wolff <[email protected]> Reviewed-by: Pavel Dubsky <[email protected]>
* Revert "Windows QPA: Move transient children with a window move"Timothée Keller2023-10-101-46/+0
| | | | | | | | | | | This reverts commit 530d092eae0579bbb88e95f853715cac214da636. Reason for revert: Moving transient children as a whole is too broad, and forces unrelated windows to have their position completely dependent on a transient parent. Fixes: QTBUG-117779 Pick-to: 6.6 6.5 Change-Id: I01312e26e95c8144c392eca33aec41f54aaa40b0 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Windows QPA: Adjust margins for Windows App SDK compatibilityTimothée Keller2023-09-131-3/+26
| | | | | | | | | | | | | | | If using the ExtendsContentIntoTitleBar() method from the Windows App SDK, the top margin becomes zero. The current approach does not account for this, since it relies on the AdjustWindowRectExForDpi function. Do a manual check after and correct if necessary, by comparing the window and client sizes. Fixes: QTBUG-113736 Pick-to: 6.6 6.5 Change-Id: I62e0338b3ff7af47f5525dcccd0f9acfe9691819 Reviewed-by: Oliver Wolff <[email protected]> Reviewed-by: Wladimir Leuschner <[email protected]> Reviewed-by: Tor Arne Vestbø <[email protected]>
* Windows QPA: also consider child windows for setting WS_EX_LAYEREDTimothée Keller2023-08-141-2/+9
| | | | | | | | | | Child windows on Windows cannot have a frame, so checking only for Qt::FramelessWindowHint is not sufficient. Add an additional check to see if the window is a native child (has the WS_CHILD flag). Pick-to: 6.6 6.5 Change-Id: Ib5cbec0f6157da687a5585e12a6c4c6935919538 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Windows QPA: Move transient children with a window moveTimothée Keller2023-06-271-0/+46
| | | | | | | | | | | | When moving a window with keyboard shortcuts, popup menus currently do not follow along. Allow this to happen by accounting for a window's transient children, and moving them after the owning window has finished its move. Fixes: QTBUG-106483 Pick-to: 6.6 6.5 Change-Id: Id51a7c0163e4fdd2d139565f2bf500a3fc997488 Reviewed-by: Oliver Wolff <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-30 01:52:53 +0000