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
What info you need ?
Try with a newer version: 7.1.0.2. See if this new version have the same behaviour.
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.
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
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.
Created attachment 165690 [details] Dark breeze default theming Start center with proposed patch applied to remove custom theme overrides.
Nice. Much better than the image from description. ;)
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.
BTW: Dark background on the left sidebar looks much better compared to first screenshot.
(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.
Looking at the picture again, maybe there should be a separator between help and extensions?
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.
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.
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?
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.
(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.
(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.
(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
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.
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.
(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.
Created attachment 166324 [details] startcenter inconsistent with dark theme
(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
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.
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.
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.
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
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.
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
(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.
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
(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.