Description: if you open the 'pivot table layout' dialog and maximize it (e.g. drag to the top of the screen in Gnome), then click on 'options' or 'source and destination' to reveal the hidden options, nothing happens. if you do so whilst not maximised it works fine. similarly, if you click on them while maximized, then drag the window by its title bar to unmaximize it, you then find that they are then expanded. thus when maximized, the change in expanded/collapsed state is being correctly recorded, but is failing to be reflected in the painted dialog. (the reason i'm maximising the dialog is due to the bottom being cut off on my display when not maximized, per bug #133124). Actual Results: Expected Results: Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 7.0.1.1.0+ Build ID: <buildversion> CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.utf8); UI: en-GB Debian package version: 1:7.0.1_rc1-1 Calc: threaded
UX-team, here is another problem with Pivot table layout dialog
What do you mean with "nothing happens"? When I expand Options with the maximized dialog it opens the respective section but resizes the field controls above. To solve the issue I recommend to make the dialog non-resizable, which is the default anyway for dialog that doesn't take user input (like file browsers). See https://wiki.documentfoundation.org/Design/Guidelines/PropertyDialog sc/uiconfig/scalc/ui/pivottablelayoutdialog.ui Window Flag > Resizable
(In reply to Heiko Tietze from comment #2) > What do you mean with "nothing happens"? When I expand Options with the > maximized dialog it opens the respective section but resizes the field > controls above. > > To solve the issue I recommend to make the dialog non-resizable, which is > the default anyway for dialog that doesn't take user input (like file > browsers). See > https://wiki.documentfoundation.org/Design/Guidelines/PropertyDialog > > sc/uiconfig/scalc/ui/pivottablelayoutdialog.ui > Window Flag > Resizable as in clicking on it does not expand/reveal the options it is hiding as expected. upon opening the dialog, clicking 'options' or 'source and destination' expands/collapses the set of controls beneath them as expected. but if you drag the dialog to the top-left in Gnome such that it is resized ('snapped'?) to fill the screen, then these controls are broken, as in you click them and they do not expand/collapse. the click action is clearly not ignored in this situation, as i said, since if you then drag the dialog to unmaximise it, the dialog is repainted with the controls in the changed expanded/collapsed state requested. the dialog is just simply not being repainted to reflect the underlying state while in maximised/snapped state. a detail that i now notice is that when you hover over such a control, it turns from black to grey while the cursor is over it. when you click the control while the dialog is maximised, the control remains stuck as grey and moving the mouse over the other such control no longer changes it to grey. thus further indication that dialog painting seems to be getting stuck. ah, another important detail i notice in writing this response, if i alt+tab between my browser and calc, this forces the dialog to be repainted. so if i click the control, it does not expand/collapse, i alt+tab away and then back, and then find that the dialog has been repainted correctly (the controls are correctly shown expanded/collapsed). the same dialog/control re-painting issue does not occur with controls like checkboxes. i.e. with 'options' expanded, if i click one of the checkboxes beneath, it immediately shows as checked/unchecked as expected without issue. resizing the dialog by dragging sizes/corners does not create the same issue. the problem only shows up snapping the dialog to fill the screen. i very much do not concur with the proposed solution of disabling resizing. - this just masks the underlying bug with repainting such controls. - i'm not sure that disabling resizing actually stops snapping to fill the screen anyway, but regardless, the reason i was doing it in the first place was to work around bug #133124 (now merged into bug #128135), and so if you block me from resizing the dialog before that other bug is resolved, then you'll be making use of pivot tables impossible for people like me affected by that bug.
(In reply to Lyndon Brown from comment #3) > as in clicking on it does not expand/reveal the options it is hiding as > expected. Thanks for clarification. Does not happen for me (6.4.6.2 VCL=kf5 and master VCL=gtk3) but I get the point. > i very much do not concur with the proposed solution of disabling resizing. > - this just masks the underlying bug with repainting such controls. > - i'm not sure that disabling resizing actually stops snapping to fill the > screen anyway, but regardless, the reason i was doing it in the first place > was to work around bug #133124 (now merged into bug #128135), and so if you > block me from resizing the dialog before that other bug is resolved, then > you'll be making use of pivot tables impossible for people like me affected > by that bug. Accepted, but once we have solved the size issue this dialog should made non-resizable (like any other).