Bug 120036 - Useless scrollbar for Gradient / Bitmap / Hatch fill selection
Summary: Useless scrollbar for Gradient / Bitmap / Hatch fill selection
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3 all versions
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Area-Fill-Tab Scrollbars
  Show dependency treegraph
 
Reported: 2018-09-21 19:39 UTC by Tamás Zolnai
Modified: 2019-03-05 09:14 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing useless toolbar for hatch tab (100.55 KB, image/png)
2018-09-21 19:40 UTC, Tamás Zolnai
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tamás Zolnai 2018-09-21 19:39:01 UTC
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:
Comment 1 Tamás Zolnai 2018-09-21 19:40:34 UTC
Created attachment 145092 [details]
Screenshot showing useless toolbar for hatch tab
Comment 2 BogdanB 2018-09-22 19:23:14 UTC
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
Comment 3 Xisco Faulí 2018-09-25 10:45:21 UTC
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 ?
Comment 4 Caolán McNamara 2018-09-25 19:43:28 UTC
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 ?
Comment 5 Maxim Monastirsky 2018-09-25 21:26:15 UTC
(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.
Comment 6 Tamás Zolnai 2018-09-28 09:08:39 UTC
(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.
Comment 7 Tamás Zolnai 2019-03-05 09:14:16 UTC
Let's close this, since this was a design decision.