Created attachment 126736 [details] Screenshot 1 on OS X without patch Change of Calc multiline dropdown button with tdf #99701 has some side effects: (1) Scrollbars of multiline dowpdown window and main window have different width on OS X (see screenshot 2 on OS X without patch) (2) Scrollbar placement is not consistent with dropdown button on Linux (see screenshot 2 on Linux without patch) Proposal shown in screenshots on OS X and Linux with patch should resolve these issues: (1) For a clear design scrollbars of main window and multiline dropdown window should be placed on top of each other exactly with same width. (2) A dropdown button without borders should be used to prevent becoming to small. Arrows have same size as dropdown arrows in toolbars now. Builds/screenshots have been taken with OS X and Linux / GTK 2. I will do an additional bulid with GTK 3 to verify that the arrow won't become garbled. In addition to inputline redesign character size has been increased to 120% of original size. This prevents very small / unreadable inputline character sizes on some OS X resolutions. Open issues: (1) On OS X expanded multiline dropdown window has a gray line as bottom border (see screenshot 2 on OS X with patch). The gray border line is not visible when dropdown window is collapsed. (2) Small button for tiling main window becomes corrupted when tooltips are shown. This can be observed when opening and closing multiline dropdown window. Both issues are not related to the patch and were present previously too. Any help is appreciated.
Created attachment 126737 [details] Screenshot 2 on OS X without patch
Created attachment 126738 [details] Screenshot 1 on OS X with patch
Created attachment 126739 [details] Screenshot 2 on OS X with patch
Screenshots for Linux will be added in brief
Created attachment 126740 [details] Screenshot 1 on Linux without patch
Created attachment 126741 [details] Screenshot 2 on Linux without patch
Created attachment 126742 [details] Screenshot 1 on Linux with patch
Created attachment 126743 [details] Screenshot 2 on Linux with patch
I prefer the current state which make the dropdown button more visible. Best regards. JBF
Adding UX team...
Agreed with JBF. The proposed change makes the button way too small. The current situation makes it prominent. On a user POV, the change would lead users to overlook this widget (well, some already do).
Created attachment 137452 [details] Without left offset Agree with the OP that it looks not too good. Tried with LEFT_OFFSET 0 and that solves the situation on Linux (Qt) but not really on macOS. Screenshot from left to right: current situation, how it looks with zero offset on Linux and on macOS. Patch is here https://gerrit.libreoffice.org/#/c/44205/ Proper solution would be to place the scrollbar right hand of the button above. Guess this is the code pointer where SetPosPixel() could be replaced. void ScInputBarGroup::Resize() ... long nWidth = pParent->GetSizePixel().Width(); long nLeft = GetPosPixel().X(); Size aSize = GetSizePixel(); aSize.Width() = std::max(long(nWidth - nLeft - LEFT_OFFSET), long(0)); maScrollbar->SetPosPixel(Point( aSize.Width() - maButton->GetSizePixel().Width(), maButton->GetSizePixel().Height() ) );
I am a fan of dropping the button border, but we should stick a colorful icon to it so it remains noticeable.
Alignment is definitely a good to have, though not crucial. Removing needsUX, setting importance to low.
Scrollbars of consistent width while keeping button large required a somewhat larger redesign. My proposed solution is integrating scrollbar with text input field while keeping button separate. I attached screenshots for macOS as well as for Linux with input bar collapsed as well as expanded.
Created attachment 143998 [details] Collapsed input bar on macOS
Created attachment 143999 [details] Expanded input bar on macOS
Created attachment 144000 [details] Collapsed input bar on Linux
Created attachment 144001 [details] Expanded input bar on Linux
Patch has been submitted to Gerrit.
(In reply to Thorsten Wagner from comment #20) > Patch has been submitted to Gerrit. Link please. On the first glance I don't like the horizontal shift and wonder why you keep the triangle (haven't looked into the issue again in detail).
Link to Gerrit: https://gerrit.libreoffice.org/#/c/58659 Triangle is needed to expand/collapse. I don’t see any other solution how to keep scrollbar width consistent with all other scrollbars within the application while keeping width of triangle (as desired above within this ticket).
(In reply to Thorsten Wagner from comment #22) > Triangle is needed to expand/collapse. Right. How about switching the expander column with the scrollbar?
Switching the expander column with scrollbar means reducing width of triangle to scrollbar width? This does not work with very thin scollbars (dependent on the widget set used). There is an assertion failure using the patch. I‘m unable to reproduce this failure neither on macOS nor on Linux (Debian). What OS platform do you use?
(In reply to Thorsten Wagner from comment #24) > What OS platform do you use? Linux, unfortunately dont have time to look into details.
Created attachment 144019 [details] Design options
I have to rebuild for debugging - this will take a while. To clarify things I attached an overview of possibile design options (see attached file "Design Options.odg").
After a lot of platform upgrades I was able to continue working on this issue. Build platforms are now macOS 10.14 and Debian 10. As Gerrit change 58659 has been abandoned in the meantime, I will commit a new change to Gerrit in short. To remove assertion failure found by Heiko I investigated vcl/source/window/toolbox.cxx. Beside the assertion failure it was possible to fix the behaviour of OK and Cancel icons, which were dangling in some situations, at this place too. With the introduction of a dropdown menu at the Sum button, button width changes when the text input field is selected. Left border of text input field changes accordingly. To ensure text input field's position after selection/deselection, a redesigned layout mode handling for Calc's formula bar was introduced in toolbox.cxx. New Screenshots of collapsed/expanded formula bar with/without selection for macOS and Linux are attached.
Created attachment 151222 [details] Collapsed input bar on macOS
Created attachment 151223 [details] Collapsed selected input bar on macOS
Created attachment 151224 [details] Expanded input bar on macOS
Created attachment 151225 [details] Expanded selected input bar on macOS
Created attachment 151226 [details] Collapsed input bar on Linux
Created attachment 151227 [details] Collapsed selected input bar on Linux
Created attachment 151228 [details] Expanded input bar on Linux
Created attachment 151229 [details] Expanded selected input bar on Linux
Change committed to Gerrit: https://gerrit.libreoffice.org/71937
Is it possible to move the functions from the left (functions, AutoSum and Formula) vertical align in rows when the Input line offers 3 rows Name Box | Function Wizard, AutoSum, Formula | Input line will change to Name Box Function Wizard Input line AutoSum Input line Formula Input line
@ Andreas: It's possible, but I suggest to do further changes step by step. @ Heiko: Button image may be replaced by an open down arrow (like in Excel) in a further step too. Committed another patch set to Gerrit. Patch set contains only a single issue criticized during the last Jenkins run.
@ Andreas: Changing arrangement of icons depending on height would cause a large space between icons and text input field. Otherwise left border of text input field is changing again. Name Box | Function Wizard, AutoSum, Formula | Input line Name Box | Function Wizard | Input line AutoSum Input line Formula Input line It's possible to adjust line height by mouse dragging furthermore. Icons would jump from initial to alternative layout while dragging. Summing up I wouldn't recommend to do so.
Thorsten Wagner committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/04b60370a73b79e3aa0a04bc7cff45dff1db6286%5E%21 tdf#101443 Calc multiline input bar reworked It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 151664 [details] Linux before the change.
Created attachment 151665 [details] Linux after the change. Notice how the content in the Input Line is slightly more glued (by one pixel or so?) to the left Input Line border now. That IMHO was better before, with a bit more spacing. Also the combobox edit fields are slightly narrower now, in fact their right border moved inwards a little.
(In reply to Eike Rathke from comment #43) > Notice how the content in the Input Line is slightly more glued (by one > pixel or so?) to the left Input Line border now. That IMHO was better > before, with a bit more spacing. Yes, a bit distance would be nice but isn't a blocker for the patch, IMHO.
Distances to left margin are not consistent throughout the application. For example Calc's sidebar has different distances for text, numbers, etc. already. Currently left and right distances are set equal to top / bottom distances. As a compromise I will set left / right distances twice of top / bottom distances. A patch containing this change will be submitted as soon as possible.
The placement of controls within a container is precisely defined. But we talk about the text within the edit field, and here again it makes sense to not start at zero but have a pixel whitespace.
I'm talking about the text within edit fied too. Distance is currently not zero but same as distance to top/bottom margins. I will set it twice for more space.
Change committed to Gerrit: https://gerrit.libreoffice.org/74214
Thorsten Wagner committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/2b4efc32e822bf41c4b729137718f3c70f692a89%5E%21 tdf#101443 Horizontal inset margin of Calc input bar increased It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #49) > Thorsten Wagner committed a patch related to this issue. Please resolve as fixed when done.
I don't quite get the increase of the font size here. If it is "unreadable on some OS X resolutions", then other UI elements (like Name Box) would be also unreadable; in general, the application UI font settings should just follow OS settings; so this part of change makes some change that looks unneeded, partial, and incorrect - if something doesn't follow OS settings, it should be fixed in a proper place and have universal effect. Currently, it just makes a single UI control inconsistent.
(In reply to Mike Kaganski from comment #51) > I don't quite get the increase of the font size here. See bug 127066.