Description: In pargraph dialog we have Area tab where we can select different kind of background fills. For Gradient fill we have some preset fills we can select from. All the preset gradient fills are visible in the list, but the list widget still have a scrollbar on the right side which we can't move to any where. Would be better to not display the scrollbar at all, if it has no function. Same issue with bitmap and hatch tab. Steps to Reproduce: 1. Open Format -> Paragraph dialog 2. Switch Area -> Gradient tab page 3. Check the list of preset gradients Actual Results: There is a scrollbar for the list, but it has no function. Expected Results: Should not be a scrollbar when all item fits into the view. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 145092 [details] Screenshot showing useless toolbar for hatch tab
Confirm it on Version: 6.2.0.0.alpha0+ Build ID: 66232248ff55639052ddb76918d555e21dc9c46b CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-20_19:40:04 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
Also reproduced in Version: 5.3.0.0.alpha1+ Build ID: 4136757b4e51c4e6f7cb4132c95538a7f831ef2c CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk3; Layout Engine: new; Locale: ca-ES (ca_ES.UTF-8); Calc: group @Caolán, I thought you could be interested in this issue. Is it possible to hide the scrollbar if all items fit in the view ?
Its doable, I think in the past we've ended up with glitches by fiddling with this though, e.g. commit 8161d9cf7649e1183e51aaa2525a9c0374205a3d Author: Maxim Monastirsky <momonasmon@gmail.com> Date: Wed Jul 4 19:38:54 2018 +0300 Fix initial width of the color palette in welded picker caolanm->maxim: what case was the above for example, is it the palette in the color dropdown case ?
(In reply to Tamás Zolnai from comment #0) > Actual Results: > There is a scrollbar for the list, but it has no function. It's intentional. See the comments in https://gerrit.libreoffice.org/28492/ (In reply to Caolán McNamara from comment #4) > caolanm->maxim: what case was the above for example, is it the palette in > the color dropdown case ? Yes it is. There was also a recent case with a ColorValueSet inside a dialog - see Bug 119299. IIRC The problem is that it's a common practice to call stuff like ValueSet::CalcWindowSizePixel from an outside code, and set its output as a size request for the control (e.g. see ColorValueSet::layoutAllVisible usage inside the ColorWindow ctor). But in the welded world, the size request is set to the drawing area, and the scrollbar width comes from a separate scrolled window. Which means that if we don't have overlay scrollbars, the drawing area needs to be enlarged when we don't want to show the scrollbar. But this shouldn't happen if the previous size request was a result of such external CalcWindowSizePixel call, as it already detected the uselessness of the scrollbar, and gave a larger area. Otherwise this will result in the scrollbar width being calculated twice.
(In reply to Maxim Monastirsky from comment #5) > (In reply to Tamás Zolnai from comment #0) > > Actual Results: > > There is a scrollbar for the list, but it has no function. > It's intentional. See the comments in https://gerrit.libreoffice.org/28492/ Hmm, I'm not sure this was the right decision to always show the scrollbar. As I know it's a general GUI concept that the scrollbar is dinamically shown / hidden depending on that whether all items are visible or not.
Let's close this, since this was a design decision.