Bug Hunting Session
Bug 101443 - Wrong width/placement of Calc multiline scrollbar
Summary: Wrong width/placement of Calc multiline scrollbar
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: All All
: low normal
Assignee: Thorsten Wagner
URL:
Whiteboard: target:6.3.0 target:6.4.0
Keywords:
Depends on:
Blocks: Scrollbars Calc-Formula-Bar
  Show dependency treegraph
 
Reported: 2016-08-10 21:16 UTC by Thorsten Wagner
Modified: 2019-08-21 06:11 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot 1 on OS X without patch (142.68 KB, image/png)
2016-08-10 21:16 UTC, Thorsten Wagner
Details
Screenshot 2 on OS X without patch (142.37 KB, image/png)
2016-08-10 21:17 UTC, Thorsten Wagner
Details
Screenshot 1 on OS X with patch (141.35 KB, image/png)
2016-08-10 21:18 UTC, Thorsten Wagner
Details
Screenshot 2 on OS X with patch (142.42 KB, image/png)
2016-08-10 21:19 UTC, Thorsten Wagner
Details
Screenshot 1 on Linux without patch (103.41 KB, image/png)
2016-08-10 23:17 UTC, Thorsten Wagner
Details
Screenshot 2 on Linux without patch (102.98 KB, image/png)
2016-08-10 23:18 UTC, Thorsten Wagner
Details
Screenshot 1 on Linux with patch (100.25 KB, image/png)
2016-08-10 23:18 UTC, Thorsten Wagner
Details
Screenshot 2 on Linux with patch (100.24 KB, image/png)
2016-08-10 23:19 UTC, Thorsten Wagner
Details
Without left offset (6.77 KB, image/png)
2017-11-02 10:28 UTC, Heiko Tietze
Details
Collapsed input bar on macOS (126.13 KB, image/png)
2018-08-06 21:15 UTC, Thorsten Wagner
Details
Expanded input bar on macOS (130.05 KB, image/png)
2018-08-06 21:15 UTC, Thorsten Wagner
Details
Collapsed input bar on Linux (73.57 KB, image/png)
2018-08-06 21:16 UTC, Thorsten Wagner
Details
Expanded input bar on Linux (75.18 KB, image/png)
2018-08-06 21:16 UTC, Thorsten Wagner
Details
Design options (14.82 KB, application/vnd.oasis.opendocument.graphics)
2018-08-07 22:56 UTC, Thorsten Wagner
Details
Collapsed input bar on macOS (24.03 KB, image/png)
2019-05-07 21:37 UTC, Thorsten Wagner
Details
Collapsed selected input bar on macOS (41.63 KB, image/png)
2019-05-07 21:38 UTC, Thorsten Wagner
Details
Expanded input bar on macOS (35.70 KB, image/png)
2019-05-07 21:38 UTC, Thorsten Wagner
Details
Expanded selected input bar on macOS (29.88 KB, image/png)
2019-05-07 21:38 UTC, Thorsten Wagner
Details
Collapsed input bar on Linux (25.28 KB, image/png)
2019-05-07 22:16 UTC, Thorsten Wagner
Details
Collapsed selected input bar on Linux (25.44 KB, image/png)
2019-05-07 22:16 UTC, Thorsten Wagner
Details
Expanded input bar on Linux (33.96 KB, image/png)
2019-05-07 22:17 UTC, Thorsten Wagner
Details
Expanded selected input bar on Linux (33.95 KB, image/png)
2019-05-07 22:17 UTC, Thorsten Wagner
Details
Linux before the change. (108.97 KB, image/png)
2019-05-24 17:56 UTC, Eike Rathke
Details
Linux after the change. (108.11 KB, image/png)
2019-05-24 18:03 UTC, Eike Rathke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Wagner 2016-08-10 21:16:51 UTC
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.
Comment 1 Thorsten Wagner 2016-08-10 21:17:45 UTC
Created attachment 126737 [details]
Screenshot 2 on OS X without patch
Comment 2 Thorsten Wagner 2016-08-10 21:18:24 UTC
Created attachment 126738 [details]
Screenshot 1 on OS X with patch
Comment 3 Thorsten Wagner 2016-08-10 21:19:05 UTC
Created attachment 126739 [details]
Screenshot 2 on OS X with patch
Comment 4 Thorsten Wagner 2016-08-10 21:20:33 UTC
Screenshots for Linux will be added in brief
Comment 5 Thorsten Wagner 2016-08-10 23:17:36 UTC
Created attachment 126740 [details]
Screenshot 1 on Linux without patch
Comment 6 Thorsten Wagner 2016-08-10 23:18:15 UTC
Created attachment 126741 [details]
Screenshot 2 on Linux without patch
Comment 7 Thorsten Wagner 2016-08-10 23:18:43 UTC
Created attachment 126742 [details]
Screenshot 1 on Linux with patch
Comment 8 Thorsten Wagner 2016-08-10 23:19:17 UTC
Created attachment 126743 [details]
Screenshot 2 on Linux with patch
Comment 9 Jean-Baptiste Faure 2016-10-02 12:06:32 UTC
I prefer the current state which make the dropdown button more visible.

Best regards. JBF
Comment 10 Xisco Faulí 2017-11-01 23:08:41 UTC
Adding UX team...
Comment 11 Jean-Francois Nifenecker 2017-11-02 05:49:55 UTC
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).
Comment 12 Heiko Tietze 2017-11-02 10:28:29 UTC
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() ) );
Comment 13 Adolfo Jayme 2017-11-03 09:32:30 UTC
I am a fan of dropping the button border, but we should stick a colorful icon to it so it remains noticeable.
Comment 14 Heiko Tietze 2018-06-14 12:50:14 UTC
Alignment is definitely a good to have, though not crucial. Removing needsUX, setting importance to low.
Comment 15 Thorsten Wagner 2018-08-06 21:13:20 UTC
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.
Comment 16 Thorsten Wagner 2018-08-06 21:15:23 UTC
Created attachment 143998 [details]
Collapsed input bar on macOS
Comment 17 Thorsten Wagner 2018-08-06 21:15:47 UTC
Created attachment 143999 [details]
Expanded input bar on macOS
Comment 18 Thorsten Wagner 2018-08-06 21:16:12 UTC
Created attachment 144000 [details]
Collapsed input bar on Linux
Comment 19 Thorsten Wagner 2018-08-06 21:16:41 UTC
Created attachment 144001 [details]
Expanded input bar on Linux
Comment 20 Thorsten Wagner 2018-08-06 21:23:53 UTC
Patch has been submitted to Gerrit.
Comment 21 Heiko Tietze 2018-08-07 10:50:40 UTC
(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).
Comment 22 Thorsten Wagner 2018-08-07 13:24:37 UTC
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).
Comment 23 Heiko Tietze 2018-08-07 13:31:31 UTC
(In reply to Thorsten Wagner from comment #22)
> Triangle is needed to expand/collapse. 

Right. How about switching the expander column with the scrollbar?
Comment 24 Thorsten Wagner 2018-08-07 15:15:37 UTC
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?
Comment 25 Heiko Tietze 2018-08-07 15:21:36 UTC
(In reply to Thorsten Wagner from comment #24)
> What OS platform do you use?

Linux, unfortunately dont have time to look into details.
Comment 26 Thorsten Wagner 2018-08-07 22:56:30 UTC
Created attachment 144019 [details]
Design options
Comment 27 Thorsten Wagner 2018-08-07 22:57:46 UTC
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").
Comment 28 Thorsten Wagner 2019-05-07 21:36:38 UTC
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.
Comment 29 Thorsten Wagner 2019-05-07 21:37:34 UTC
Created attachment 151222 [details]
Collapsed input bar on macOS
Comment 30 Thorsten Wagner 2019-05-07 21:38:01 UTC
Created attachment 151223 [details]
Collapsed selected input bar on macOS
Comment 31 Thorsten Wagner 2019-05-07 21:38:33 UTC
Created attachment 151224 [details]
Expanded input bar on macOS
Comment 32 Thorsten Wagner 2019-05-07 21:38:58 UTC
Created attachment 151225 [details]
Expanded selected input bar on macOS
Comment 33 Thorsten Wagner 2019-05-07 22:16:26 UTC
Created attachment 151226 [details]
Collapsed input bar on Linux
Comment 34 Thorsten Wagner 2019-05-07 22:16:52 UTC
Created attachment 151227 [details]
Collapsed selected input bar on Linux
Comment 35 Thorsten Wagner 2019-05-07 22:17:14 UTC
Created attachment 151228 [details]
Expanded input bar on Linux
Comment 36 Thorsten Wagner 2019-05-07 22:17:44 UTC
Created attachment 151229 [details]
Expanded selected input bar on Linux
Comment 37 Thorsten Wagner 2019-05-08 00:32:35 UTC
Change committed to Gerrit: https://gerrit.libreoffice.org/71937
Comment 38 andreas_k 2019-05-08 22:02:32 UTC
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
Comment 39 Thorsten Wagner 2019-05-08 22:20:49 UTC
@ 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.
Comment 40 Thorsten Wagner 2019-05-08 22:44:22 UTC
@ 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.
Comment 41 Commit Notification 2019-05-24 17:54:44 UTC
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.
Comment 42 Eike Rathke 2019-05-24 17:56:07 UTC
Created attachment 151664 [details]
Linux before the change.
Comment 43 Eike Rathke 2019-05-24 18:03:34 UTC
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.
Comment 44 Heiko Tietze 2019-05-25 08:15:58 UTC
(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.
Comment 45 Thorsten Wagner 2019-05-30 23:01:26 UTC
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.
Comment 46 Heiko Tietze 2019-06-01 07:37:17 UTC
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.
Comment 47 Thorsten Wagner 2019-06-01 10:28:12 UTC
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.
Comment 48 Thorsten Wagner 2019-06-17 20:35:36 UTC
Change committed to Gerrit: https://gerrit.libreoffice.org/74214
Comment 49 Commit Notification 2019-07-18 08:09:55 UTC
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.
Comment 50 Heiko Tietze 2019-07-20 12:18:51 UTC
(In reply to Commit Notification from comment #49)
> Thorsten Wagner committed a patch related to this issue.

Please resolve as fixed when done.
Comment 51 Mike Kaganski 2019-08-20 13:41:48 UTC
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.
Comment 52 Thomas Lendo 2019-08-21 06:10:20 UTC
(In reply to Mike Kaganski from comment #51)
> I don't quite get the increase of the font size here.
See bug 127066.