Created attachment 198841 [details] Demonstration video To reproduce, on a 900px-high single-monitor setup on GNOME 47's Wayland session on Fedora 41: 1. open the Pivot Table dialog window; it opens at full height of the screen (which is nice) 2. click to expand the "Options" or "Source and Destination" sections of that dialog Result: the height keeps expanding beyond the maximum height of the screen, and goes off-screen. See attached video for a quick demonstration of the issue. ------- A bit similar to bug #164910, but not specific to multi-monitors here, it happens on any monitor, particularly those with limited height in their resolution (ex: 1600x900 pixels resolution). A bit similar to bug #128135, but affects the latest stable LibreOffice version: Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded
One thing that came to my mind afterwards: if shrinking the other widgets (i.e. the 5 listviews in the upper part, when expanding the extra options widgets in the lower part) is considered problematic compared to the current shapeshifting dialog, maybe a different UI widgets approach can be considered for those expanders: using the equivalent of a popover* widget to contain them, and show the popover by clicking some buttons instead of expanders; that way the extra settings would be temporarily overlaid on top of the rest of the dialog, without resizing involved. *: https://docs.gtk.org/gtk4/class.Popover.html
Edge case since the Source/Destination is rarely needed. Similar to the print dialog we could add a scrolled window behind the controls that requires to scroll but keep the entire dialog on the screen. Alternative UI proposal in bug 131654.
We discussed the topic in the design meeting. + named range and selection could be placed in one line + we may add a scrolled window behind the options + move options and source/destination into extra tabs + options could use a three column layout Ultimately we should aim for a table configuration via the sidebar with the idea that users not only create reports but also repeatedly rearrange data with the feature. Code pointer: sc/uiconfig/scalc/ui/pivottablelayoutdialog.ui