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
There is a scrollbar for the list, but it has no function.
Should not be a scrollbar when all item fits into the view.
User Profile Reset: No
Created attachment 145092 [details]
Screenshot showing useless toolbar for hatch tab
Confirm it on
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
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.
Author: Maxim Monastirsky <firstname.lastname@example.org>
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.