aboutsummaryrefslogtreecommitdiffstats
path: root/src/quickcontrols/fluentwinui3
Commit message (Collapse)AuthorAgeFilesLines
* QuickControls: Fix linkage of controls stylesUlf Hermann3 days1-0/+1
| | | | | | | | | | | | They need to link the styles they import so that the dependencies are clarified (and also they'll in fact need the linkage if we ever compile them in direct mode). Pick-to: 6.10 Task-number: QTBUG-137440 Change-Id: I6edaba4390dce4f9cc2b95586f28331192cc01ff Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix QQuickIconLabel action icon color being overridden by style defaultMitch Curtis14 days11-119/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Styles need a way to set the default icon color for controls. Until now, that was done like this: icon.color: "tomato" contentItem: IconLabel { icon: control.icon } This breaks the use case of e.g. an Action that sets its own icon.color, because the icon property of the control always takes precedence (see 146bc9517c56feda4eba34282d3cc53bd47b6267). This patch adds a defaultIconColor property to IconLabel, which allows styles to specify a color without overriding any potential action's icon: contentItem: IconLabel { icon: control.icon defaultIconColor: "tomato } If icon.color was explicitly set, it is used instead. This does mean that overriding the contentItem will result in the icon color being lost, but that is already the case for style customizations in general. All controls that set icon.color and using IconLabel to display their icon are affected and are therefore adapted: Button, CheckDelegate, DelayButton, ItemDelegate, MenuBarItem, MenuItem, RadioDelegate, RoundButton, SwipeDelegate, SwitchDelegate, TabButton, ToolButton. Add FlowPane to the shared folder of the baseline test and use it in the tests that we touch. This fixes two issues: - Using Pane as the background fixes text being invisible for some styles. - Using Flow provides the most space-efficient layouting of items now that we have more than would fit in the old layout. Task-number: QTBUG-87459 Change-Id: I455ce7202a46b7cfa7545650574e48ad72796675 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Context menus: rename control to editorMitch Curtis2025-11-123-8/+8
| | | | | | | | | | | | | | This better reflects what it is and avoids naming conflicts with the controls themselves. Pick down to 6.9 (where QQuickContextMenu was introduced) to avoid future cherry-pick conflicts. Task-number: QTBUG-133556 Task-number: QTBUG-134903 Pick-to: 6.9 6.10 Change-Id: If0af26c5f16ee56cc909fcc66d1421109786343e Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Change PopupType of textEditingContextMenu for Popup.Item on WaylandFrederic Lefebvre2025-10-311-1/+1
| | | | | | | | | | | | | | | | Use Popup.Item popupType when test is run on Wayland. Remove the need for a transient parent on Wayland that was causing several tests of tst_QQuickTextField to consistently fail. Fix the following failing tests on Ubuntu 24.04 wayland tst_QQuickTextField::contextMenuCopy, contextMenuCut, contextMenuDelete, contextMenuPaste, contextMenySelectAll, releaseAfterPressAndHold, touchscreenDoesNotSelect. Pick-to: 6.10 Change-Id: I5a411dae63ae36361ed83055a1eb4c87de17acae Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3: Fix ComboBox size when the model changesKaj Grönholm2025-10-092-9/+7
| | | | | | | | | | | | | | | | The problem was that enter Transition dynamically adjusts from and to values and these values are not up-to-date. Also, transition animates height property while from and to also depend on it. Solve this by animating instead __heightScale with non changing from & to values, so synchronizing property changes are not needed. Do the same change for Menu that uses a similar approach. Pick-to: 6.10 6.8 Task-number: QTBUG-138744 Change-Id: Ibede68a2d20ef437e0bc1637b5177f10c62935dd Reviewed-by: Doris Verria <doris.verria@qt.io>
* FluentWinUI3: Fix text color of RoundButton for high contrast themesOliver Eftevaag2025-09-231-0/+8
| | | | | | | | | | | | | The RoundButton was overlooked in 34c542aba10113440b84dca05994987e27cb8bcf when we originally fixed Button and DelayButton. It makes sense that RoundButton gets the same treatment. Fixes: QTBUG-129088 Pick-to: 6.10 Change-Id: I55110440794ac229cbc755e8fc00373097fdf058 Reviewed-by: Benedikte Holm <benedikte.holm@qt.io> Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Set explicit default security level of all files with default securityJan Arve Sæther2025-09-1759-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | The files (folders) already processed are listed in each issue in epic QTBUG-134547 These files were processed half a year ago. In order to make it clear that all of these files are already processed, mark them with an explicit default security header. For the record, this was generated with this script: find -E . -regex ".*\.(cpp|h|hpp|mm|qml|js)$" | xargs python3 ~/bin/add-cra-header.py in the folders listed in each subtask of QTBUG-134547 (add-cra-header.py only exist at my desktop, but it simply adds the default security header if it doesn't already have any existing security header) QUIP: 23 Fixes: QTBUG-134547 Pick-to: 6.10 6.9 6.8 Change-Id: Ieb8c78ea6561fdbdd27c7b13185ece853eedf80f Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* FluentWinUI3: Improve RadioButton when using high contrast themesOliver Eftevaag2025-08-281-4/+28
| | | | | | | | | | | | | | | | | | | The RadioButton's indicator would not use the same colors as the WinUI3 RadioButton for users that had enabled a high contrast theme. The indicator background is normally a ColorImage. But for high contrast themes we prefer to keep things simple, and draw simple colors on top of the image. It is possible to change the binding on the ColorImage to use desired high contrast theme colors from the palette, but doing so will slightly alter the colors used, due to blending with the pixel values from the underlying png image used by ColorImage. Thus we put a rectangle on top, so that high contrast themes become independent from it. Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: I57ef286584f7df2c26bacbc0bc9f3bcb7a1a64cd Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* FluentWinUI3: Improve CheckBox when using high contrast themesOliver Eftevaag2025-08-281-39/+82
| | | | | | | | | | | | | | | | | | | | | | | | The CheckBox indicator uses a ColorImage to blend the pixels of a png image file together with a QColor, in order to determine the colors that the indicator should use in any given state (e.g, checked, unchecked, hovered, etc). Unfortunately, blending the ColorImage with a color has its limitations when enabling a high contrast theme on Windows 11, such as when the checkbox is in the pressed and unchecked state, where the color image background will typically be mostly black, and this make the color bound on the color property much darker, or in this case, completely black. To get around this issue, we now have a Rectangle on top of the ColorImage, which is normally transparent, except for when high contrast is enabled. In that case, it will be rendered on top, and use the exact desired colors. Pick-to: 6.10 Task-number: QTBUG-129088 Change-Id: Ic65218d3759495611772f010c86a85109faaaadd Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* FluentWinUI3: Improve Slider and RangeSlider with high contrast themesOliver Eftevaag2025-08-262-22/+135
| | | | | | | | | | | | | | | The Slider and RangeSlider wasn't using the correct colors, for users that had enabled a high contrast theme. They also relied on StyleImages for both the backgrounds and the handles. Use basic Rectangles instead of StyleImages when using a high contrast theme, with the appropriate colors, in order to make the control look as similar as possible to the native WinUI 3 controls. Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: Ib30a10c15124ab444b9ca4dd501d6e2c75478fcc Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* SearchField: Use highlightedIndex instead of currentIndex in stylesDilek Akcay2025-08-111-2/+2
| | | | | | | | | | As highlightedIndex property is added to SearchField, relevant style implementations that previously relied on currentIndex have been updated to use highlightedIndex. Pick-to: 6.10 Change-Id: Ib8bc065c92aa95a1ea5ea3cd5c3825bbd15c2f2d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add set_source_files_properties for SearchFieldDilek Akcay2025-08-061-0/+4
| | | | | | | | | | Added set_source_files_properties to configure build settings for SearchField in 6.10. Found in 6.10 QML API review, QTBUG-137478. Pick-to: 6.10 Change-Id: Ieff5ff3c737ee2c9ddd7a261333eea777d7ef03e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3: Improve SearchField indicatorsDoris Verria2025-07-231-25/+30
| | | | | | | | | | | | | The SearchField indicators draw a background when hovered/pressed which was not showing on light mode because it was using a white color. Instead of drawing the background ourselves use image assets from the Spinbox indicator-s as they share the same style. In addition, use a palette color for the indicator icons as well as change the opacity when it is pressed. Pick-to: 6.10 Change-Id: I4f4413cb408d80d2167ca52b98cefdf4b51f25f2 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* FluentWinUI3: Resolve palette against platform theme and app's palette when ↵Doris Verria2025-07-173-31/+43
| | | | | | | | | | | | | | | | | updating When we were updating the theme as a result of the color scheme change, we were just updating the palette to the default colors, forgetting to resolve against the theme palette and the guiApp palette. This was different from the palette initialization logic, which resolves against both platform and app palette, making the style palette inconsistent between the initial palette and the updated one after the color scheme change. To fix, use the same logic when both initializing and updating the palette. Also, refactor some code and function names. Pick-to: 6.10 6.9 6.8 Change-Id: I80a0983509323002e8d422b79c5271c312d8d963 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* FluentWinUI3: Improve the ProgressBar when using high contrast themesOliver Eftevaag2025-07-161-10/+12
| | | | | | | | | | | | | | | | | | The ProgressBar would continue to use the same background, even when a contrast theme was applied. Not only did this cause the background to have the wrong colors, but it also lacked the outline that the native WinUI3 ProgressBar has. Fix it by using a regular Rectangle as the background item in case a high contrast theme is being used. In addition, we reduce the inset by 1 pixel, in order to make room for the new outline, without affecting the size of the contentItem. Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: I9b67d89d86f7d7d556c0461e34e2f23e4fb0a0be Reviewed-by: Doris Verria <doris.verria@qt.io>
* FluentWinUI3 Style: Set QPalette::Base roleDoris Verria2025-07-151-1/+8
| | | | | | | | | | According to the docs, QPalette::Base color is based on the color of text input backgrounds. Set this for the FluentWinUI3 Style based on text input colors from the WinUI3 guidelines. Pick-to: 6.10 Change-Id: I407fc221c31ec265e8f36279d887f2605f419f33 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Add FluentWinUI3 Style for SearchFieldDilek Akcay2025-07-148-0/+205
| | | | | | | Task-number: QTBUG-137318 Pick-to: 6.10 Change-Id: I30bb7161d23c9723842b4dd7ea346dd8a85fb6d9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* FluentWinUI3: Give Popup an outline when using high contrast themesOliver Eftevaag2025-07-091-0/+11
| | | | | | | Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: I48948c40aa8de9de0663d976f179c14fd3e700ae Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* FluentWinUI3: Give GroupBox an outline when using high contrast themeOliver Eftevaag2025-07-091-3/+9
| | | | | | | Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: I2e64190ecfe8a2dd63daaf3ec5f30b9dbf18ac3a Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* FluentWinUI3: Give the Frame an outline when using high contrast themeOliver Eftevaag2025-07-091-2/+11
| | | | | | | Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: Id14b7b65b6178e43af6859444600bf134134efaa Reviewed-by: Doris Verria <doris.verria@qt.io>
* FluentWinUI3: Give Menu an outline when using high contrast themesOliver Eftevaag2025-07-071-5/+17
| | | | | | | Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: I4aa8de77d147bc68dfea28b51037b0a33bd7f2d2 Reviewed-by: Doris Verria <doris.verria@qt.io>
* FluentWinUI3 style: Don't set imlicitWidth for combobox content itemDoris Verria2025-07-071-2/+0
| | | | | | | | | | | | | | | | | We were setting the implicitWidth of the combobox's inner text field to depend on the width of the content (ie: text). However, for an editable combobox this means that the textField will expand horizontally as you type to accomodate for the new typed text. This is not wanted behavior. To fix, don't manually set the implicitWidth to the content item, as a text field already has its own implicit size. Note that "implicitResize", which controls whether the textfield recalculates its implicit size when its content changes, is set to false by default for a text field. Pick-to: 6.8 6.9 6.10 Change-Id: I2f7ca2706dc2957fd600a0c06dc28010bfb4f7c6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* FluentWinUI3: Improve Dialog when using high contrast themesOliver Eftevaag2025-07-032-10/+23
| | | | | | | | | | | | | | The Dialog type was lacking the iconic outline which Dialogs get when high contrast themes are enabled on Windows 11. Add it to both Dialog, and DialogButtonBox, and make adjustments in order to make a Dialog with and without a DialogButtonBox look similar to a Windows App SDK ContentDialog, when using a high contrast theme. Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: Ie158a46566dceaa343f9120cc44969b410b5abe4 Reviewed-by: Doris Verria <doris.verria@qt.io>
* FluentWinUI3: Give MenuBarItem an outline when using high contrast themeOliver Eftevaag2025-06-272-6/+9
| | | | | | | | | | | | Items in the MenuBar has an outline with a similar color to the text inside the MenuBarItem, when using a high contrast theme on Windows 11. Make the FluentWinUI3 styled MenuBarItems look similar. Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: I5508a2e387d3d3662bff8f2433383cda486dc65f Reviewed-by: Doris Verria <doris.verria@qt.io>
* FluentWinUI3: Improve the Switch when using high contrast themesOliver Eftevaag2025-06-161-12/+23
| | | | | | | | | | | | | The Switch didn't use the correct colors, for users that were using high contrast themes on Windows 11. Fix it by using appropriate palette colors when the contrast preference setting is set to HighContrast. Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: Ic751d43c26edc52b1e791ddbede2ae2fca029857 Reviewed-by: Doris Verria <doris.verria@qt.io>
* FluentWinUI3: Improve ComboBox when using high contrast themesOliver Eftevaag2025-06-162-16/+51
| | | | | | | | | | | | | | | | The ComboBox didn't use the correct colors, for users that were using high contrast themes on Windows. It relied on StyleImage's to display the background, which we can't use under high contrast mode. Fix by using Rectangle's instead, and change colors where it makes sense to do so. Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: I4a4863002325eb48cd93d2e841f63b62824e2d60 Reviewed-by: Doris Verria <doris.verria@qt.io>
* FluentWinUI3 style: Support high contrast theme for ButtonDoris Verria2025-06-154-31/+67
| | | | | | | | | | | | | | | | | | On Windows platforms there are several high contrast themes. These themes follow a different and much lighter palette than the normal FluentWinUI3 one. They mainly use a combination of 4 colors, as gotten from the system: COLOR_BTNFACE, COLOR_BTNTEXT, COLOR_HIGHLIGHT, and COLOR_HIGHLIGHTTEXT. To support these, when detecting that a high contrast theme is in use, don't initialize and resolve the style palette but just use the platorm theme's palette as that is initialized with the correct system colors. So far only add support for Button. Task-number: QTBUG-129088 Pick-to: 6.10 Change-Id: I4b241c2e0a89c6d7f151a31a21d600b9e6a7d7b9 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* FluentWinUI3 Style: Hide private QML propertiesDoris Verria2025-03-2030-377/+378
| | | | | | | | | The style declares several QML dynamic properties which are meant to be private. Hide them using __ convention. Pick-to: 6.9 6.8 Change-Id: I4317d2ee7072a72fda1736fc8c9165a980889d95 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Menu: adjust the insets according to the drop shadowRichard Moe Gustavsen2025-03-202-8/+17
| | | | | | | | | | | | | | | | | | | As it stood, the background delegate of a Menu would draw its drop shadow on the outside of the delegate, and therefore also on the outside of the Menu as a whole. This works fine for Popup.Item, since an Item is allowed to draw out-of-bounds. But for Popup.Window, this would fail. Instead, the correct solution in this case is to draw the shadow _inside_ the delegate, and instead make the whole menu bigger by adjusting the insets instead, to take the shadow into account. In order to be able to do this, we also need to teach StyleImage to optionally draw the shadow inside the bounds. Pick-to: 6.9 6.8 Change-Id: I306e511abca44f4f86ee18a16740f679cf987ac1 Reviewed-by: Doris Verria <doris.verria@qt.io>
* ContextMenu: add to text editing controlsMitch Curtis2025-02-289-0/+90
| | | | | | | | | | | [ChangeLog][Controls] TextField and TextArea now provide a ContextMenu by default. If you already have a custom context menu for these types, ContextMenu will not open its own on e.g. right click. Fixes: QTBUG-35598 Pick-to: 6.9 Change-Id: I0897a7ba5e1b5b6d5425c80cbc6f2550c904605b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3: Move StyleImage to private impl moduleDoris Verria2025-01-1625-52/+130
| | | | | | | | | | | | | | Follow the approach with FocusFrame and move StyleImage.qml to the private FluentWinUI3.impl module instead. Add deprecation warnings to the original file. [ChangeLog][QtQuick][Controls][FluentWinUI3] StyleImage.qml is deprecated in the module's public QML API and moved to the private impl module instead. Pick-to: 6.9 Change-Id: I2a536591abb2172a1f7d7a052e88f0c2f58cd481 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3: Move FocusFrame type to private impl moduleDoris Verria2025-01-158-9/+93
| | | | | | | | | | | | | | | FocusFrame.qml was included in the FluentWinUI3 public module imports, despite not providing any documentation. This component is an implementation detail and should not be part of public QML API. Add deprecation warnings in the original file and move it to the private impl module instead. [ChangeLog][QtQuick][Controls][FluentWinUI3] FocusFrame.qml is deprecated in the module's public QML API and moved to the private impl module instead. Pick-to: 6.9 Change-Id: I74c8c9a03ccc1f7b33d6fb814ca1faeca57b0545 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FocusFrame: Don't remove binding on visible propertyDoris Verria2024-12-201-2/+0
| | | | | | | | | | | | | When calling moveToItem() when the focus object changes, we were explicitly assigning the visible property. This caused the previous binding declared on the visible property of the frame to be removed. To fix, don't assign the visible property on moveToItem, as the binding on the target item and its visibility will take care of that. Ammends 945c3a98edac75cac082b1719c380a0bae861944. Pick-to: 6.8 6.9 6.5 Change-Id: I504a0e00000c5fdfb8c5193b9fa2314199a7c4e0 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Compute implicitSize based on implicitContentSize in Popup and subclassesTor Arne Vestbø2024-12-194-8/+8
| | | | | | | | | | | | Popup uses a Pane as its popup item, so now that Pane reflects its explicitly set contentWidth/Height through implicitContentWidth/Height we can use the same expression for implicit width/height as regular controls, which hooks us into the safe area binding loop detection as well. Pick-to: 6.9 Change-Id: I3709978dae0271d7daf44fc6988f09f03df15b1f Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Take safe areas into account for Qt Quick Controls ToolBar and MenuBarTor Arne Vestbø2024-12-192-8/+8
| | | | | | | | | | | | | | | A ToolBar and MenuBar is commonly placed in the header/footer/menuBar of an ApplicationWindow, where we don't do any automatic padding to account for the safe area. By adding the safe area margins as padding to the controls, we ensure that the control's background flows into the non-safe area, while the content item of the control (the toolbar or menu bar content) is kept within the safe area. Pick-to: 6.9 Change-Id: I5fad7394beaa01ae8ed142e4e2e42c5bffaab9fa Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Compute implicitSize based on implicitContentSize in Container and subclassesTor Arne Vestbø2024-12-182-4/+4
| | | | | | | | | | | | Now that Container reflects its explicitly set contentWidth/Height through implicitContentWidth/Height we can use the same expression for implicit width/height as regular controls, which hooks us into the safe area binding loop detection as well. Pick-to: 6.9 Change-Id: If0a710a5eb4a35c91d02d7170b5e03e457e6bc12 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Compute implicitSize based on implicitContentSize in Pane and subclassesTor Arne Vestbø2024-12-183-6/+6
| | | | | | | | | | | Now that Pane reflects its explicitly set contentWidth/Height through implicitContentWidth/Height we can use the same expression for implicit width/height as regular controls, which hooks us into the safe area binding loop detection as well. Pick-to: 6.9 Change-Id: Ie31b740a1e405341fc5f0ed9673b213292e4afd9 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* FluentWinUI3: Show focus frame when focus reason is from arrow keysDoris Verria2024-12-181-5/+5
| | | | | | | | | | | | | | | | | | We don't have a Qt::FocusReason enumerator value that represents the focus reason being arrow keys, so for cases that an item gains focus due to arrow-key navigating, the focus reason will be OtherFocusReason. The FluentWinUI3 style only draws the focus frame when the focus reason was Tab/Backtab to avoid drawing it for focus reasons other than keyboard focus, but it should draw it for when focus shifts due to arrow keys too, so include Qt::OtherFocusReasons in the conditions. Also, reset the focus frame when we can't find a focus object AND when the focus reason is none of the above in order to avoid showing the frame around an item that lost focus because of another reason. Fixes: QTBUG-130328 Pick-to: 6.8 6.9 Change-Id: I6cbc13124a0e672bf453896bafd0ba1d8656449e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Focus frame: Don't delete focus frame whenever new focus item is nullDoris Verria2024-12-181-1/+4
| | | | | | | | | | | | | | | | | | When we didn't find a new target focus item we would destroy the focus frame object and recreate it the next time a new valid focus item is found. This can be expensive due to cleanup and reallocation calls, and it can also lead to a crash during parent destruction because the focus frame gets deleted as part of the parent item's destruction, potentially triggering changes in the focus object that result in another attempted deletion of the focus frame. Instead, in case of an invalid new focus item, we should just set the focus frame's target item to null when calling moveToItem. This will handle that case by making the frame invisible and setting its parent to null. Pick-to: 6.9 6.8 Change-Id: Icf46af0ce3c79bab09343a2262688fb33ed8a4d9 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* FocusFrame: Remove the kludge with the invisible root itemJan Arve Sæther2024-12-181-27/+21
| | | | | | | | | | | Now when we call setTransparentForPositioner(true) on the focus frame, there is no need to keep the root item with size(0,0). The only purpose of having that item was so that layouts would ignore the focus frame. Pick-to: 6.8 6.5 6.9 Change-Id: I6224dced83c054b573eb682997e238a0cf1f4776 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Doris Verria <doris.verria@qt.io>
* Mark the focus frame as transparent for positionersJan Arve Sæther2024-12-032-4/+3
| | | | | | | | | | | | | Applies to the focus frame on macOS, Windows and FluentWinUI3 style. This will ensure that it is excluded by layouts and positioners. Previously, layouts excluded items with 0x0 size, so setting the size of the focus frame to 0x0 worked then. This is not the case any longer. Pick-to: 6.8 6.5 Fixes: QTBUG-129427 Change-Id: I399317f8a7a6b941803556e7ffb2208ad3237726 Reviewed-by: Doris Verria <doris.verria@qt.io>
* QQuickFocusFrame: Fix showing focus frame inside embedded qquickwidgetDoris Verria2024-09-181-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In QQuickFocusFrame, we connect to QGuiApplication::focusObjectChanged signal and draw the focus frame around focusObject() of qGuiApp, which as per its implementation, is the focusObject() of the app's focusWindow(). However, in the case of QQuickWidget, its offscreenWindow will never become the focusWindow of the application because it doesn't have a native handle. Also, since 0dbc575c1a8359534761167a5f5f1e29abedd51d QQuickWidget intentionally doesn't override the focusObject method to return the focusObject of its offscreen window because that would bypass needed event handling logic in qquickwidget. That is why if a qquickwidget has active focus, qGuiApp will report the qquickwidget itself as its focusObject, rather than the focusObject inside of the widget. However, we still do propagate focus object changes inside the qquickwdiget's offscreen window up to the top level widget and the application, so that when the offscreen's window QQuickWindow::focusObjectChanged is emitted, the equivalent signal in QGuiApplication will also be emitted. That is why in qquickfocusframe we should rely on the signal parameter instead, which represents the right focus object, rather than query qGuiApp::focusObject(). While we're at it, reset the focus frame if no item inside the quick window currently has active focus, otherwise we would still show a focus frame even if the quick window lost focus. Note: Ideally qGuiApp::focusObject() should give us the same object as the QGuiApplication::focusObjectChanged signal parameter, but that can require more work as the focusObject() of the application will then receive key events and qquickwidget relies on handling those key (and other) events itself. Fixes: QTBUG-128931 Pick-to: 6.8 6.8.0 Change-Id: Id86a4e9dfd6b2bda5cc9ea633305e71d86fcdb5f Reviewed-by: MohammadHossein Qanbari <mohammad.qanbari@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* FluentWinUI3 Style: Add SwipeDelegateDoris Verria2024-09-062-0/+67
| | | | | | | Task-number: QTBUG-125279 Pick-to: 6.8 Change-Id: Ia1f35705cd1f6ff912294ddce172bde381789fbb Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3: Show focus frame only if focusReason was from tab/backtabDoris Verria2024-09-022-12/+14
| | | | | | Pick-to: 6.8 Change-Id: Ib2b98ba7f69d70b251bfa17e35ee121c7728b916 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3 Style: Add focus frame componentDoris Verria2024-08-3021-3/+230
| | | | | | | | | | | | | Add a FocusFrame component that follows the active focus item, mirroring the approach used by the native styles with QQuickFocusFrame. In the future, this should probably move out of the native style and serve as a common solution across all styles. Task-number: QTBUG-125279 Pick-to: 6.8 Change-Id: I577d0b783c36bc7e146a7e02051195d78a11ca60 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3 Style: Add ToolTipDoris Verria2024-08-303-0/+71
| | | | | | Pick-to: 6.8 Change-Id: I962b1d9a3aa0e2dbcdc9d262088de00e5abd3322 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3 Style: Add Dialog/DialogButtonBoxDoris Verria2024-08-304-1/+141
| | | | | | | | | | | Add Dialog and DialogButtonBox. While at it, remove them from the list of not-yet supported controls in the Fluent style docs, together with other controls that have already been implemented. Pick-to: 6.8 Change-Id: I6abe0cae8712a999a5491b5ec1a904df56d38d0d Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3 Style: Add RoundButton and DelayButtonDoris Verria2024-08-303-0/+179
| | | | | | | Task-number: QTBUG-125279 Pick-to: 6.8 Change-Id: I400c3ccc27088427481a86cc937597675649fb3d Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3: Support button and accent palette roles for Button/ToolButtonDoris Verria2024-08-30139-165/+238
| | | | | | | | | | | | | We want to be able to support custom palette.accent and palette.button colors for the Button/ToolButton. To do that, use QML instead of images for the button background and factor it out in reusable component ButtonBackground. Remove previously generated images for the button/toolbutton backgorunds but keep using geometry information generated from the stylegenerator. Pick-to: 6.8 Change-Id: I6f195b32142d06c96833ac3d9184da9f8bbd22ba Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FluentWinUI3 Style: Adjust ToolSeparator paddingsDoris Verria2024-08-301-4/+5
| | | | | | | | | The horizontal/vertical paddings need to be inverted depending on orientation. Pick-to: 6.8 Change-Id: Ia9d516088a749e0c29e70d06bc24a83f1ffb6f3b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-01 20:21:16 +0000