https://bugs.documentfoundation.org/show_bug.cgi?id=120036
--- Comment #5 from Maxim Monastirsky <[email protected]> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
