Download it now!
Bug 136555 - StartCenter is inconsistent with dark theme(s)
Summary: StartCenter is inconsistent with dark theme(s)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.3 target:7.0.4
Keywords: bibisectRequest, needsUXEval, regression
Depends on:
Blocks: Start-Center KDE
  Show dependency treegraph
 
Reported: 2020-09-07 16:50 UTC by medmedin2014
Modified: 2020-11-16 15:22 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Main launch window is inconsistent with dark theme (126.00 KB, image/png)
2020-09-07 16:50 UTC, medmedin2014
Details
Dark breeze default theming (179.75 KB, image/png)
2020-09-19 19:49 UTC, Jan-Marek Glogowski
Details
Before/after the patch in c12 (123.44 KB, image/png)
2020-09-21 08:24 UTC, Heiko Tietze
Details
startcenter inconsistent with dark theme (140.91 KB, image/png)
2020-10-12 19:31 UTC, medmedin2014
Details
6dfbab4 applied, SC button bar on Windows with default theme (47.75 KB, image/png)
2020-10-28 19:09 UTC, V Stuart Foote
Details
Current (2020-10-29) state of things with Adwaita theme on Fedora33 (231.66 KB, image/png)
2020-10-31 19:38 UTC, V Stuart Foote
Details
Current (2020-10-29) with Adwaita Dark theme on Fedora33 (219.41 KB, image/png)
2020-10-31 19:45 UTC, V Stuart Foote
Details
Windows Grey Eve (150.90 KB, image/png)
2020-10-31 21:07 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description medmedin2014 2020-09-07 16:50:27 UTC
Created attachment 165243 [details]
Main launch window is inconsistent with dark theme

The foreground color of font in the left sidebar of the main launch window does not respect the dark theme. See attached image for more info.

LibreOffice
Version: 7.0.0.3
Build ID: 7.0.0-1
CPU threads: 2; OS: Linux 5.8; UI render: default; VCL: kf5
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Operating System: Manjaro Linux
KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
Kernel Version: 5.8.3-2-MANJARO
OS Type: 64-bit
Comment 1 medmedin2014 2020-09-18 20:52:55 UTC
What info you need ?
Comment 2 BogdanB 2020-09-18 20:57:16 UTC
Try with a newer version: 7.1.0.2.

See if this new version have the same behaviour.
Comment 3 V Stuart Foote 2020-09-18 22:39:48 UTC
Spun up a VM with Manjaro 20.1 KDE with Breeze Dark theme set.

For default LO 6.4.6.2 it is correct, SC foreground color (the labels) are dark over the light grey bg. The active SC button takes a light fg on a dark bg. 

Did pacman update to libreoffice-fresh package and dependencies including kio "for KF5 KDE desktop integration".

With 7.0.1.2 and Breeze Dark theme, the Start Center fg text is White on a light grey bg as shown in clip, the active button light fg on dark bg looks fine.
Comment 4 V Stuart Foote 2020-09-18 22:40:25 UTC
Version: 7.0.1.2
Build ID: 00(Build:2)
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: kf5
Locale: en-US (en_US.UTF-8); UI: en-US
=7.0.1-1
Calc: threaded
Comment 5 Jan-Marek Glogowski 2020-09-19 19:45:32 UTC
Broken since commit:

commit 8d11b953c0a69f4f5eb5ca42dec3812a62d0cd0f
Author: Thorsten Wagner <thorsten.wagner.4@gmail.com>
Date:   Sun Feb 23 21:11:05 2020 +0100

    tdf#125532: White text on default/action buttons and selected tabs on macOS

and IMHO made worse by

commit 84b2849512bdb19597739d9515dd55e2d3ba9504
Author: Thorsten Wagner <thorsten.wagner.4@gmail.com>
Date:   Tue Jul 28 00:36:07 2020 +0200

    tdf#134708 Text coloring of buttons within forms amended

which will hit users in 7.0.2 and master.

But honestly I'm not sure about a good fix.

If you have any "advanced" theming of buttons on your platform, it might include a different background of the button in various states.

So maybe it's sensible to ignore the foreground color, if you don't set a custom background. OTOH I really doubt this is a sensible and understandable constraint for any form designer in Base. Maybe Base shouldn't use any theming to begin with. Anyway, commit 84b2849512bdb19597739d9515dd55e2d3ba9504 adds a new constraint.

Fact is the current state is broken and it'll be more broken in 7.0.2, when the 2nd patch hits the users.

As a fix for the start center, I simply dropped button theming: https://gerrit.libreoffice.org/c/core/+/103041

That was decided and introduced in bug 90452.

Or we want a platform setting, so the start center button theming can be ignored by some platforms, like kf5?

Also notice, that the "Create" label has a different / correct font color.
Comment 6 Jan-Marek Glogowski 2020-09-19 19:49:23 UTC
Created attachment 165690 [details]
Dark breeze default theming

Start center with proposed patch applied to remove custom theme overrides.
Comment 7 BogdanB 2020-09-19 19:51:25 UTC
Nice.
Much better than the image from description. ;)
Comment 8 Thorsten Wagner 2020-09-19 20:09:06 UTC
An alternative implementation to fix the issue may be as follows:

(1) Currently a stock (non native) control is used when setting a custom background.

(2) Instead of ignoring foreground when no custom background is set, the same approach may be used: If a custom foreground is set, a stock control and not the native one will be choosen.
Comment 9 Thorsten Wagner 2020-09-19 20:10:38 UTC
BTW: Dark background on the left sidebar looks much better compared to first screenshot.
Comment 10 Jan-Marek Glogowski 2020-09-19 20:49:20 UTC
(In reply to Thorsten Wagner from comment #8)
> An alternative implementation to fix the issue may be as follows:
> 
> (1) Currently a stock (non native) control is used when setting a custom
> background.
> 
> (2) Instead of ignoring foreground when no custom background is set, the
> same approach may be used: If a custom foreground is set, a stock control
> and not the native one will be choosen.

(1) Sometimes. The VCL plugin can indicate in Sal::Graphics::isNativeControlSupported, if it supports custom backgrounds for a native control. Support was extended lately at least to handle colors by bug 136094.

(2) I tried this by applying the control background in the start center. But then even gen looks broken, because the fixed background means rollover highlight wouldn't apply, so you basically just get a border. Totally unusable.
Comment 11 Jan-Marek Glogowski 2020-09-19 21:39:43 UTC
Looking at the picture again, maybe there should be a separator between help and extensions?
Comment 12 Thorsten Wagner 2020-09-20 23:08:01 UTC
Commited a patch to gerrit to prevent ignoring of button text label color when no custom background is set:

https://gerrit.libreoffice.org/c/core/+/103079

As I am only able to test on macOS currently, testing is required with QT, GTK and on Windows.

BTW: Using a stock (non native) control when setting a custom background was implemented prior to patch for tdf#125532. This is implemented in a way that fallback to stock control is done independet of support of custom background by native widget set. The patch committed does not change this behaviour.
Comment 13 Heiko Tietze 2020-09-21 08:24:16 UTC
Created attachment 165710 [details]
Before/after the patch in c12

The patch is not a solution. I'm on KDE with Breeze Dark and the black font becomes dark as the background with the patch. Same when compiled for gtk3 or qt5.

The start center has user-defined colors (StartCenterBackgroundColor, StartCenterBackgroundColor, and StartCenterTextColor). This is pointless- who would customize the start center?, and detrimental to accessibility, see bug 99116. 

We should always use system colors.
Comment 14 Thorsten Wagner 2020-09-21 08:43:21 UTC
The patch should only solve handling of custom foreground colors when no custom background is set. The behaviour observed here seems to be another problem not related to VCL button color handling.

Has dark theme on Startcenter sidebar ever worked before?
Comment 15 Heiko Tietze 2020-09-21 09:07:19 UTC
Don't call it dark theme, it's just an undocumented "feature" for no good reason, AFAICS. My registry is clean, to my knowledge, the colors take values from sources.
Comment 16 V Stuart Foote 2020-09-21 13:26:22 UTC
(In reply to Heiko Tietze from comment #15)
> Don't call it dark theme, it's just an undocumented "feature" for no good
> reason, AFAICS. My registry is clean, to my knowledge, the colors take
> values from sources.

And please remember we have limited ability for 'theming' coming in from Windows WDM and remain unable to support MS' UWP era Dark Mode (bug 118320), nor for macOS theming (bug 118017). 

The StartCenterBackgroundColor, StartCenterForgroundColor expert configuration stanzas are provided for cross platform support.
Comment 17 Jan-Marek Glogowski 2020-09-22 19:22:51 UTC
(In reply to V Stuart Foote from comment #16)
> (In reply to Heiko Tietze from comment #15)
> > Don't call it dark theme, it's just an undocumented "feature" for no good
> > reason, AFAICS. My registry is clean, to my knowledge, the colors take
> > values from sources.
> 
> And please remember we have limited ability for 'theming' coming in from
> Windows WDM and remain unable to support MS' UWP era Dark Mode (bug 118320),
> nor for macOS theming (bug 118017).

The problem is that just these two (StartCenterBackgroundColor and StartCenter*Text*Color) are used to override the themed push buttons color and text. It's simply not realistic to result in any reasonable theming that way. That is why my patch simply drops them. 

This is independent from the bunch of "StartCenterThumbnails*" settings, which are used in the main start center area for fixed colors of that area.

And as you can see in Heiko's image, currently the "Help" and "Extensions" buttons also have the wrong background. From the StartCenterBackgroundColor, they are actually correctly themed.

And this has nothing to do with any platform theming, but with LO overriding part of the push button theming, resulting in some awkward UI. That's why I proposed to remove the overrides all together.

> The StartCenterBackgroundColor, StartCenterForgroundColor expert
> configuration stanzas are provided for cross platform support.

I'm actually not sure, what this should be used for. I can imagine some "vendor" customization to set some different background on the left button bar. But this shouldn't affect the buttons at all, because they need to provide at least highlight colors too.
Comment 18 Heiko Tietze 2020-09-23 07:37:34 UTC
(In reply to Jan-Marek Glogowski from comment #17)
> I proposed to remove the overrides all together.

+1000, never mess with background and font color
Comment 19 Thorsten Wagner 2020-09-23 09:14:24 UTC
Although

https://gerrit.libreoffice.org/c/core/+/103079

does not resolve this issue, it removes possibile dependencies between custom foregrounds and backgrounds. With patch it is possbile to set custom foreground independent of custom background.

So I suggest applying this patch by general reasons, but again: As I am not able to test with GTK,QT, and Windows right now, patch should be tested on these widget sets using light appearance too to avoid unwanted side effects.

Currently I do not know about other overrides due to tdf#134708 and tdf#125532.
Comment 20 Commit Notification 2020-10-07 02:13:21 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a927e0964ba0442d53fffb22c577e54bcf183ed7

tdf#136555 drop custom start center button colors

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 medmedin2014 2020-10-12 19:30:15 UTC
(In reply to Commit Notification from comment #20)
> Jan-Marek Glogowski committed a patch related to this issue.
> It has been pushed to "master":
> 
> https://git.libreoffice.org/core/commit/
> a927e0964ba0442d53fffb22c577e54bcf183ed7
> 
> tdf#136555 drop custom start center button colors
> 
> It will be available in 7.1.0.
> 
> The patch should be included in the daily builds available at
> https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
> information about daily builds can be found at:
> https://wiki.documentfoundation.org/Testing_Daily_Builds
> 
> Affected users are encouraged to test the fix and report feedback.

with appimage (I can't install non appimage LO 7.0.2 on Manjaro because there is no dev version for archlinux only deb and rpm supported):

Version: 7.0.2.2
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: kf5
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

The problem is still persistent. See attached image for more info.
Comment 22 medmedin2014 2020-10-12 19:31:21 UTC
Created attachment 166324 [details]
startcenter inconsistent with dark theme
Comment 23 Jan-Marek Glogowski 2020-10-13 03:05:45 UTC
(In reply to medmedin2014 from comment #21)
> (In reply to Commit Notification from comment #20)
> >
> > It will be available in 7.1.0.
> > 
> Version: 7.0.2.2
> Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
> 
> The problem is still persistent. See attached image for more info.

Eventually the (blind) backport will make it into 7.0.3...

See: https://gerrit.libreoffice.org/c/core/+/104048
Comment 24 Commit Notification 2020-10-14 08:35:22 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/59290d7a12868a04e90ccbde1f5871fb8be49af8

tdf#136555 drop custom start center button colors

It will be available in 7.0.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 25 Commit Notification 2020-10-27 09:51:31 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6dfbab409032516e05a63fbc777b9147d1deb4ec

tdf#136555 apply window bg color for button boxes

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 26 Commit Notification 2020-10-28 14:27:22 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/804f051e8504338ada4ab1fe958aa7fc66a1297c

tdf#136555 apply window bg color for button boxes

It will be available in 7.0.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 27 V Stuart Foote 2020-10-28 19:09:48 UTC
Created attachment 166817 [details]
6dfbab4 applied, SC button bar on Windows with default theme

So the SC window bg color is now being applied. As it is not being themed on Windows it is rather garish. Clip is a side-by-side new handling on left, old on  right.

Not sure this is workable. May need resolution of bug 118320  

Version: 7.1.0.0.alpha1+ (x64)
Build ID: a4d4ed86991e2901ac86189e95966d4e99be4944
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 28 V Stuart Foote 2020-10-31 19:38:21 UTC
Created attachment 166895 [details]
Current (2020-10-29) state of things with Adwaita theme on Fedora33

Recent (20201029) master/7.1.0.0Alpha1+ RPM parallel installed on Fedora 33

Screen clip compare SC of 7.0.2.2 to master/7.1.0 with default Adwaita theme.

Same affect for the SC button bar background as on Windows - garish.

But, it does look more presentable when using Adwaita Dark them.
Comment 29 V Stuart Foote 2020-10-31 19:45:04 UTC
Created attachment 166896 [details]
Current (2020-10-29) with Adwaita Dark theme on Fedora33

Guess this was the issue that started these tweaks to SC, the 7.0.2.2 clip is ugly with Adwaita Dark 


Fedora 33 64-bit guest VM on Windows 10 with Oracle VirtualBox

Version: 7.0.2.2
Build ID: 00(Build:2)
CPU threads: 1; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 30 Jan-Marek Glogowski 2020-10-31 19:54:57 UTC
(In reply to V Stuart Foote from comment #28)
> Created attachment 166895 [details]
> Current (2020-10-29) state of things with Adwaita theme on Fedora33
> 
> Recent (20201029) master/7.1.0.0Alpha1+ RPM parallel installed on Fedora 33
> 
> Screen clip compare SC of 7.0.2.2 to master/7.1.0 with default Adwaita theme.
> 
> Same affect for the SC button bar background as on Windows - garish.

Feel free to suggest an other themed color. Currently it uses rStyleSettings.GetWindowColor(), because the default == GetWorkspaceColor() looks worse / too dark and is wrong, because it's the same then the background around the Writer document.
Comment 31 V Stuart Foote 2020-10-31 21:07:59 UTC
Created attachment 166897 [details]
Windows Grey Eve

(In reply to Jan-Marek Glogowski from comment #30)
> (In reply to V Stuart Foote from comment #28)
> > Created attachment 166895 [details]
> > Current (2020-10-29) state of things with Adwaita theme on Fedora33
> > 
> > Recent (20201029) master/7.1.0.0Alpha1+ RPM parallel installed on Fedora 33
> > 
> > Screen clip compare SC of 7.0.2.2 to master/7.1.0 with default Adwaita theme.
> > 
> > Same affect for the SC button bar background as on Windows - garish.
> 
> Feel free to suggest an other themed color. Currently it uses
> rStyleSettings.GetWindowColor(), because the default == GetWorkspaceColor()
> looks worse / too dark and is wrong, because it's the same then the
> background around the Writer document.

Sorry but that is just it. The old "Branded" StartCenter did not require theming--it was "designed" as a brand--replacing of the old start panel and incorporating thumbnail views of documents held internally (to LO profile) on the recent documents history. The whole thing was designed to be monolithic. Avoiding theming coming in from os/DE.

As Windows DWM does not support theming (except when signaling a HighContrast mode) there has been no 'Dark mode' to worry about. And providing functional themeing for Windows builds requires native code for LO to pick up the UWP color schemes and map them for LO use. That remains the crux of bug 118320

Absent needed dev work on that, if using a HighContrast signaled theme it collapses colors of the assigned theme components. The best DE theme of that means is the GreyEve theme. It actually looks reasonable with these recent SC background and text color changes. The main menu receives no contrast. Attached clip shows 7.0.3.1 and current 20201030 master (ec1f4d3253) with Grey Eve high contrast theme enabled. Note the hardcoded activation of Sifr icon theme.

Until Windows builds can respond to UWP theming, my suggestion would be to drop os/DE themeing for the SC and instead devise a static dark mode to complement the previous light mode SC "branding" that had existed. Selecting one or the other comparing luminance of FG text and BG -- the mix of grey scale colors available to the StartCenter UI seems sufficient for both flavors of BG, FG and button selections.

=-ref-=

[1] https://github.com/nitschis/GreyEveTheme
Comment 32 Jan-Marek Glogowski 2020-10-31 21:33:30 UTC
(In reply to V Stuart Foote from comment #31)
> Created attachment 166897 [details]
> Windows Grey Eve
> 
> (In reply to Jan-Marek Glogowski from comment #30)
> > (In reply to V Stuart Foote from comment #28)
> > > Created attachment 166895 [details]
> > > Current (2020-10-29) state of things with Adwaita theme on Fedora33
> > > 
> > > Recent (20201029) master/7.1.0.0Alpha1+ RPM parallel installed on Fedora 33
> > > 
> > > Screen clip compare SC of 7.0.2.2 to master/7.1.0 with default Adwaita theme.
> > > 
> > > Same affect for the SC button bar background as on Windows - garish.
> > 
> > Feel free to suggest an other themed color. Currently it uses
> > rStyleSettings.GetWindowColor(), because the default == GetWorkspaceColor()
> > looks worse / too dark and is wrong, because it's the same then the
> > background around the Writer document.
> 
> Sorry but that is just it. The old "Branded" StartCenter did not require
> theming--it was "designed" as a brand--replacing of the old start panel and
> incorporating thumbnail views of documents held internally (to LO profile)
> on the recent documents history. The whole thing was designed to be
> monolithic. Avoiding theming coming in from os/DE.

You already provided the bad variants in your images. I'm not aware the buttons were not themed, as you can see in the dark images before the patches. Same for the menu bar.

And also the menu bar in the attachment 166897 [details] is unusable. I didn't touch that at all. It's the same for the menu bar in the Win 10 high contrast themes. The background of the menu bar doesn't match the theme and the font color is wrong, taking notepad as a reference. Also the font color is wrong and I couldn't find the right one, used in notepad.

> As Windows DWM does not support theming (except when signaling a
> HighContrast mode) there has been no 'Dark mode' to worry about. And
> providing functional themeing for Windows builds requires native code for LO
> to pick up the UWP color schemes and map them for LO use. That remains the
> crux of bug 118320
> 
> Absent needed dev work on that, if using a HighContrast signaled theme it
> collapses colors of the assigned theme components. The best DE theme of that
> means is the GreyEve theme. It actually looks reasonable with these recent
> SC background and text color changes. The main menu receives no contrast.
> Attached clip shows 7.0.3.1 and current 20201030 master (ec1f4d3253) with
> Grey Eve high contrast theme enabled. Note the hardcoded activation of Sifr
> icon theme.
> 
> Until Windows builds can respond to UWP theming, my suggestion would be to
> drop os/DE themeing for the SC and instead devise a static dark mode to
> complement the previous light mode SC "branding" that had existed. Selecting
> one or the other comparing luminance of FG text and BG -- the mix of grey
> scale colors available to the StartCenter UI seems sufficient for both
> flavors of BG, FG and button selections.

I don't understand you. If I select a high-contrast theme in Win 10 most of LO correctly changes the color. So I don't understand what you mean by this comment. Is this more in regard to a whole application theming? I'm just talking about colors here for fonts and parts of the UI.

Regarding a "dark SC", that is currently not possible, because for Linux I'm not aware this is in any way advertised. The theme engine simply provides other colors and draws stuff differently, but nothing identifies as dark, except for the name - sometimes.

For MacOS we would have to swith the whole implementation to Cocoa / NSDocument, to have a way to support this. If I understood tml_ correctly.

And from all I read about Windows dark mode, there isn't a stable identifier either currently. AFAIK you wrote somewhere, that Chrome uses some hacks, which work most times, so I wouldn't even want to walk into this.