Created attachment 170820 [details] Style preview problems Style preview doesn't reflect how style are arranged, when user click on any style it will be moved to be viewed at first item, this should be when user select a text with a style and that style is not visible then it makes sense to show it as first item but not when a user click on an already shown style in styles preview. Scrolling (by mouse wheel) down/up doesn't show all styles, and scroll top and down buttons behave weirdly (they skip some styles). See attached video for more info. Operating System: Manjaro Linux KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Kernel Version: 5.4.105-1-MANJARO OS Type: 64-bit Graphics Platform: X11 Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 4566bcbf03c1b7b0c1ce3a83fee1d195f0ff7059 CPU threads: 2; OS: Linux 5.11; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-03-22_14:46:06 Calc: threaded
I confirm it with Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 807d059d99e7b99fe45a712428befa17ffa44858 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Additional problem: You can move the list up with keyboard arrow, but not with clicking arrow up in toolbar (but of course this might be a different bug report)
*** Bug 142366 has been marked as a duplicate of this bug. ***
*** Bug 144581 has been marked as a duplicate of this bug. ***
Scrolling was fixed in bug 143391. Scrollbar arrows also work, so the problem mentioned in comment 1 is gone. I will change the summary to be about the topic of styles moving around when selecting. I will make this a UX topic and set back to unconfirmed, because I think it was a deliberate decision to make the preview behave like this.
(In reply to Buovjaga from comment #4) > I think it was a deliberate decision to make the preview behave like this. What I could imagine causing of issue is the application-driven selection, eg. after pressing enter on a H1 you get Text Body. And this item needs to be highlighted consequently. But the style also changes when you ally H1 to a text. So we need a conditional update of the list only when the actual item is out of the view. => NEW
This is fixed in: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 5b2848413883565c48d312c96daf8fbca25405d8 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-10-11_23:38:53 Calc: threaded Marking as "Works For Me".
Actually, I am reopening it because the selected style does _not_ jump to the beginning of the row when using GTK3: Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: c7500945fc5d5bd2130a2d38be0bd4b15445cd90 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded ...but it _does_ jump to the beginning of the row when using the generic VCL pluging (i.e. with the option SAL_USE_VCLPLUGIN=gen): Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: c7500945fc5d5bd2130a2d38be0bd4b15445cd90 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: x11 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded So it looks like the issue is confirmed in the following VCL plugins: - gen - win - kf5
So that is the problem of our implementation of IconView widget (vcl/source/treelist/iconview.cxx). Gtk3 uses it's own native system widget.
(In reply to stragu from comment #7) > Actually, I am reopening it because the selected style does _not_ jump to > the beginning of the row when using GTK3: The correct behavior it should never put the selected item ito first position, because it's already visible and selected so why should it be moved ?