Since bug 120697 "Calc: Drop-down on 'Sum' button" is implemented, the input line is moving leftwards if a command is active that hides the drop-down arrow at the sum button. This shows a moving UI element and it shouldn't do that. My suggestion is to implement a sum button that shows a greyed-out arrow if there are no drop-down features available. That avoids a moving input line in the right of the button.
Adding keyword needsUXEval to ask the design team for input. Steps to reproduce for this issue: 1. Open a new Calc sheet. 2. Double-click in a cell. The input line is moving to the left a little bit. The drop-down arrow at the sum button is gone. 3. Type enter to move to a new cell (without clicking in it). The input line is moving back to the right and showing the drop-down arrow at the sum button again.
Thomas, do you want that new drop-down widget will show always? Now, if you are in cell edit mode then formula bar shows us another buttons (X and V) and it was always in LO. I can't repro your steps...
Created attachment 151725 [details] Screenshot of the issue The issue is not solved by disabling the dropdown - or do you also want to keep the cancel/accept buttons? Or get rid of it in favor of the keyboard input escape/enter. Also a bad solution is to mess up with the toolbar autosizing capability, ie. add programmatically some whitespace under a certain condition. I'd say it's a WF.
The "UI movement" if any is negligible as the wider Autosum split button (∑▾) and Formula (=) button pair is swapped with narrower Reject (✗) and Accept (✓) buttons as a cell/formula bar entry is being made. On Windows builds at least--the collapsed Formula bar, aka INPUT LINE, does not reposition, only the placement of the Formula (=) vs. Accept (✓) shifts by the extra width of the split button. And it is nothing compared to the movement when the Formula Bar is expanded. Frankly not seeing an issue with the half a button shift as the Formula bar is not affected. If we had to hold the button stable, could reorder them to place the wider Sigma split button at the end adjacent to the Formula Bar, but that might be uncomfortable for folks used to the Formula (=) being there. IMHO => WF
Resolving as WF since we do not have a good solution. And as of Stuart's comment, the issue is minor.
Issue should be fixed with tdf#101443
(In reply to Thorsten Wagner from comment #6) > Issue should be fixed with tdf#101443 Hard to believe since the context sensitive toolbar buttons have different size. But anyway, even better when fixed ;-).
(In reply to Heiko Tietze from comment #7) > (In reply to Thorsten Wagner from comment #6) > > Issue should be fixed with tdf#101443 > > Hard to believe since the context sensitive toolbar buttons have different > size. But anyway, even better when fixed ;-). This is exactly the reason for some changes in toolbox.cxx. It would be nice to get a feedback that issue is really fixed - from my point of view it is.
(In reply to Thorsten Wagner from comment #8) > > > Issue should be fixed with tdf#101443 > ... to get a feedback that issue is really fixed - from my point of view it is. Tested on macOS and the toolbar is utterly static. Great work! (Thorsten: feel free to set the status on tickets yourself.)