Bug 125530 - UI: Moving INPUT LINE after implementing a drop-down sum button
Summary: UI: Moving INPUT LINE after implementing a drop-down sum button
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-Formula-Bar
  Show dependency treegraph
 
Reported: 2019-05-27 19:30 UTC by Thomas Lendo
Modified: 2019-06-07 05:55 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of the issue (10.13 KB, image/png)
2019-05-28 08:00 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lendo 2019-05-27 19:30:31 UTC
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.
Comment 1 Thomas Lendo 2019-05-27 19:35:57 UTC
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.
Comment 2 Roman Kuznetsov 2019-05-27 20:21:42 UTC
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...
Comment 3 Heiko Tietze 2019-05-28 08:00:12 UTC
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.
Comment 4 V Stuart Foote 2019-06-04 12:12:57 UTC
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
Comment 5 Heiko Tietze 2019-06-06 12:16:03 UTC
Resolving as WF since we do not have a good solution. And as of Stuart's comment, the issue is minor.
Comment 6 Thorsten Wagner 2019-06-06 12:50:56 UTC
Issue should be fixed with tdf#101443
Comment 7 Heiko Tietze 2019-06-06 14:57:58 UTC
(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 ;-).
Comment 8 Thorsten Wagner 2019-06-06 19:21:28 UTC
(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.
Comment 9 Heiko Tietze 2019-06-07 05:55:11 UTC
(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.)