Bug 133311 - [HiDPI] Icon bar not filled when using Theme from Personalization option - background should always span across full width of top icon bar
Summary: [HiDPI] Icon bar not filled when using Theme from Personalization option - ba...
Status: RESOLVED DUPLICATE of bug 131023
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.4.3.2 release
Hardware: All macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-23 15:26 UTC by steve
Modified: 2021-12-15 17:15 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
theme not applied correctly after changing window wifth (50.24 KB, image/png)
2020-05-23 15:27 UTC, steve
Details

Note You need to log in before you can comment on or make changes to this bug.
Description steve 2020-05-23 15:26:34 UTC
Description:
Themes should always span across full width of top icon bar

Steps to Reproduce:
1. open LibreOffice > Preferences > Personalization
2. select preinstalled theme and apply
3. open LO with samll window size
4. increase width of window

Actual Results:
The theme on the top bar does not dynamically change width, actually remaining at the same width, leaving the top icon bar in unusable state.

Expected Results:
Either good defaults should be supported and Personalization be removed from LO (preferred) or if personalization is to be kept, the top icon bar should always be filled with the correct background.


Reproducible: Always


User Profile Reset: No



Additional Info:
Honestly, it would probably be best to remove themes from LO and be done with the mess. Then focus on providing a good default dark and light mode for all OS instead. Then add some logic to icon styles. When a user selects a dark icon style automatically apply a dark background (currently dark icons are almost invisible on the default background). And vice versa when a light icon style is selected, apply a light background.
Comment 1 steve 2020-05-23 15:27:41 UTC
Created attachment 161193 [details]
theme not applied correctly after changing window wifth
Comment 2 Maliha 2020-06-16 20:48:03 UTC
Hello steve -_- ,

Thank you for reporting the bug. Unfortunately I can't reproduce in

Version: 7.1.0.0.alpha0+ (x86)
Build ID: 4c4b3218b8595a9809ffade0cfd064f3d9335dff
CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Vulkan; VCL: win
Locale: en-CA (en_CA); UI: en-US
Calc: threaded

Could you please try to reproduce it with a master build from https://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 3 steve 2020-07-06 19:00:08 UTC
Still reproducible with release from today:
Version: 7.0.0.1
Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd
CPU threads: 8; OS: Mac OS X 10.15.5; UI render: default; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded
Comment 4 Buovjaga 2020-07-11 17:52:55 UTC
Seems to be Mac-only as I can't repro on Linux

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: 57fedb272cfcad3436142dbe9eac2870e3c3e3d2
CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 9 July 2020
Comment 5 Roman Kuznetsov 2020-07-11 18:16:53 UTC
no problem in

Version: 7.1.0.0.alpha0+
Build ID: 92c2318db92c3f102243ef1f8a9a492796932ff6
CPU threads: 4; OS: Mac OS X 10.15.5; UI render: default; VCL: osx
Locale: ru-RU (ru_RU.UTF-8); UI: en-US
Calc: threaded

nor in

Version: 7.0.0.1.0+
Build ID: 74d3471e74478a18c5a54ed4e9be83a5c0aadd8b
CPU threads: 4; OS: Mac OS X 10.15.5; UI render: default; VCL: osx
Locale: ru-RU (ru_RU.UTF-8); UI: en-US
Calc: threaded
Comment 6 steve 2020-07-11 18:37:07 UTC
Further testing: not reproducible on 15" macbook pro nor on 27" imac.
Reproducible still with 7.0.0.1RC1 on a 43" 4k monitor with scaled resolution 3360 x 2160.
Comment 7 Alex Thurgood 2020-09-16 09:10:20 UTC
No repro with 

Version: 7.0.1.2
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

and the Yellow theme. Is the problem dependent on a particular theme ?

The refresh/redraw lags a little on my screen, but when I extend the window it does get refreshed/redrawn.

Output Monitor : 30,5 pouces (1920 x 1080)
Comment 8 Alex Thurgood 2020-09-16 09:12:05 UTC
(In reply to Alex Thurgood from comment #7)


> and the Yellow theme. Is the problem dependent on a particular theme ?
> 

Answer to self - independent of theme chosen.
Comment 9 zedslaugh+libreoffice 2021-03-29 07:14:08 UTC
This issue is still present and it happens independed of DPI settings for me.
Happens with every theme.
The themes width does not expand past 3000 pixels in width.

Display resolution is 3840*2160

Version: 7.1.1.2 (x64) / LibreOffice Community
Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676
CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 10 V Stuart Foote 2021-05-20 21:36:35 UTC
It affects Windows builds as well, the PNG theme graphics max out at 3000px filled from right side to left. Initial controls of the top bar do not have a background.

Testing on dual headed 1920 x 1200px so desktop is 3840px. Dragging LO (any module or startcenter) out past 3000px width exhibits issue with a Tools -> Options -> Personalization 'Preinstalled Themes' selected active.

To me this is a dupe of bug 131023, which is marked Linux--difference is the Linux builds seem to fill from the left to right, while Windows and macOS fill from right to left.
Comment 11 V Stuart Foote 2021-05-20 21:37:13 UTC
(In reply to V Stuart Foote from comment #10)

that was on Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 12 V Stuart Foote 2021-05-20 21:42:23 UTC

*** This bug has been marked as a duplicate of bug 131023 ***