Bug 152184 - Dark Mode: Application Colors > Color Scheme should automatically follow System Settings > Appearance
Summary: Dark Mode: Application Colors > Color Scheme should automatically follow Syst...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.5.0.0 alpha0+
Hardware: All All
: medium enhancement
Assignee: Heiko Tietze
URL:
Whiteboard: target:7.6.0 inReleaseNotes:7.6
Keywords:
: 152221 152270 154559 (view as bug list)
Depends on:
Blocks: macOS-UI-polish Dark-Mode
  Show dependency treegraph
 
Reported: 2022-11-23 10:54 UTC by steve
Modified: 2024-04-06 06:04 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description steve 2022-11-23 10:54:28 UTC
Description:
Probably fair to assume that for the majority of users light and dark theme is sufficient and they won't enjoy fiddling with scattered settings.

When switching appearance in macOS System Settings for LibreOffice there is the special case that users also have to open LO > Preferences > Application Colors and change > Color Scheme to match Appearance.

Steps to Reproduce:
Change Appearance on macOS and note that various elements are not changed. Those elements are covered in LibreOffice > Preferences > Application Colors > Color Scheme.

Actual Results:
Manual change required.

Expected Results:
Automatically change Color Scheme to follow to macOS System Settings > Appearance.


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1435c5b12646269e2b5b58ec7d51626dce6505db
CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: en-US
Calc: threaded
Comment 1 Julien Nabet 2022-11-25 07:57:08 UTC
Caolán: as tdf#152183, thought you might be interested in this one since it concerns dark mode in macOS
Comment 2 Caolán McNamara 2022-11-25 11:28:05 UTC
With the fix for bug #152183 the ui will automatically update to match the current mode. So some of the "automatic" ones like "Application Background" will switch from light to dark and so on.

However it sounds a bit like this report wants to automatically switch the application color scheme from "LibreOffice" to "LibreOffice Dark". We don't do this for dark mode for Windows or Gtk and it doesn't happen for macOS either. I'm not sure we want to do that, its not really WYSIWYG if we do it, but if we do then its not a mac specific issue.

I suggest to wait until the fix for #152183 is in, and if that's not what's wanted then change this to a general platform-unspecific dark-mode request for the UITeam to determine.
Comment 3 V Stuart Foote 2022-11-28 16:07:41 UTC
*** Bug 152270 has been marked as a duplicate of this bug. ***
Comment 4 V Stuart Foote 2022-11-28 16:12:25 UTC
*** Bug 152221 has been marked as a duplicate of this bug. ***
Comment 5 V Stuart Foote 2022-11-28 16:45:32 UTC
The LibreOffice 'Application Colors' "LibreOffice" color scheme is not sufficiently granular to address all elements of the UI. But what is there is set to "Automatic" and will respond to the os/DE provided theme color actually exposed to LibreOffice.

On the other hand, the current "LibreOffice Dark" color scheme (bug 141986) used many hard coded color assignments, and was necessary because both Windows and macOS require a lot of missing native code be implemented to fully read os/DE provided color theme.

Additionally, the application colors are fully in user control and they can be manually reset from "Automatic" to any UI colors they'd like, and to save and reapply as a personal color scheme.

Meaning, we already have all that is needed. A change to switch to the fixed color "LibreOffice Dark" color scheme would not improve things cross platform. 

Rather, improving the framework for the Application Colors and implementing the native code needed to fully respond to os/DE provided color theme would be better in the long run.
Comment 6 V Stuart Foote 2022-12-04 17:46:22 UTC
Sill needs UX-Advise, no agreement on how or if to address => UNCONFIRMED
Comment 7 Heiko Tietze 2022-12-05 09:02:43 UTC
We distinguish between application colors (AC) and system colors (SC). SC come into play for normal UI controls, like the background on dialogs, the color of buttons, the font. AC are used for specific content such as the document background, grid/helplines on the canvas etc. SC are read from the OS, which is tricky sometimes. AC are defined for bright and dark themes, the later with the theme Breeze Dark in mind at the beginning but later it got more contrast, for example.

We cannot mix SC and AC and adjust one AC with something that is defined on the OS. If users create a pink theme the AC will not blend nicely. => WF

(In reply to steve from comment #0)
> Change Appearance on macOS and note that various elements are not changed.

This would be hard to resolve.
Comment 8 V Stuart Foote 2022-12-05 13:55:47 UTC
from dupe bug 152270#c3  Sierk Bornemann 2022-12-05 13:21:29 UTC
<clip>
I side with steve.

Why not following the way, the OS vendor shows how to do it on its own platform with same or similar apps to achieve consistency platform-wide?
Take TextEdit.app on macOS: how presents TextEdit.app itself on macOS in dark mode? With a white paper background or a dark/black background? TextEdit has a dark/black background, not a white paper background.
Take for instance another Texteditor, a third party Texteditor, take TextMate: dark or wihite background in ddark mode? It has a dark background. Take CotEditor, another Texteditor app: also a dark theme, a dark background, when system wide dark mode is enabled.

So, where is the problem, to follow, what the OS vendor, in this case Apple, shows how to to it on its own platform? To be consistent on the platform, on *each* of the OS platforms, with its unique requirements and pecularities should weigh higher than to be consistent across several platforms while ignoring the platform specific requirements and peculiarities, above all on the macOS platform, where this is a very special topic and the users also expect it, otherwise they do not use the software or only reluctantly and prefer to use software that adheres to this kind of consistency and specifications and where this is better observed.

</clip>
Comment 9 V Stuart Foote 2022-12-05 14:22:53 UTC
(In reply to Sierk Bornemann from comment #8)
> from dupe bug 152270#c3  Sierk Bornemann 2022-12-05 13:21:29 UTC

> I side with steve.
> 
> Why not following the way, the OS vendor shows how to do it on its own
> platform with same or similar apps to achieve consistency platform-wide?

And that requires we implement extensive native code to do so. As a cross-platform project we are resource constrained and unable to follow the latest os/DE widget and UI development. Implementing the same features 3 or 4 times in "native" code is resource intensive. Both to code and to maintain.

Cross-platform functionality is the core metric--and that does not require exclusively "native" code for each feature. Just when it is necessary to function.

Adopting each DE's native code framework is unachievable.

Here the ask is be to more completely consume os/DE theme and apply with greater granularity to our Application colors. AC that admittedly need to be refactored to accommodate a mix of system theme and application UI elements.  That is a cross platform task requiring a mix of "native" and core framework code to achieve effectively.

The WONTFIX for macOS here is fair, but os/DE theming of SC and LibreOffice AC does need to be rearchitected as to specific goals. How much "native" code do we want/need to implement and support in a cross-platform context.
Comment 10 Heiko Tietze 2022-12-06 16:14:16 UTC
AC consists of ~50 colors while SC is limited to 10. There is no way to completely get rid of it. My take is to follow with AC the SC but allow to edit it. Ideally per extension.
Comment 11 steve 2023-02-02 15:25:37 UTC
This is not limited to macOS, setting OS to all, since at least also windows is affected.
Comment 12 steve 2023-02-02 15:29:23 UTC
*** Bug 153329 has been marked as a duplicate of this bug. ***
Comment 13 Heiko Tietze 2023-02-03 10:37:34 UTC
*** Bug 153334 has been marked as a duplicate of this bug. ***
Comment 14 Heiko Tietze 2023-02-20 14:48:21 UTC
Since the OP in bug 153334 didn't accept the duplicate state let's bring the same requests together the other way.

*** This bug has been marked as a duplicate of bug 153334 ***
Comment 15 Sierk Bornemann 2023-03-02 03:02:17 UTC
FYI, just for info, maybe it might help to orientate and maybe follow the same way, because it's not bad and has proved its worth:


Microsoft Support document: Dark Mode in Word – Word for Microsoft 365, Word for Microsoft 365 for Mac, Word 2021
https://support.microsoft.com/en-us/office/dark-mode-in-word-e17b79a3-762f-4280-a81c-a15a859a693a#ID0EDD=MacOS

Incl. what and how to change the settings to change/adjust the defaults. Sidenote (see screenshots and text in the document): for example, among other things: the default page background in dark mode is: a _dark_ page background, not a white one per default.

<blockquote>
Dark Mode in Word offers a dark color scheme for both the menu controls and the document background. Dark Mode can help to reduce eye strain and also provides a more modern feel to Word. The dark page background does not convey how your document will print, or the default view your collaborators will see when they open it.

…

Turn on Dark Mode

To turn on Dark Mode in the Word, you need to enable Dark Mode for Mac OS.

1. Go to Settings > General

2. In the Appearance options, select Dark

[Screenshot]

Alternatively, you can select Auto, which will switch between Light and Dark modes based on your specified Night Shift schedule in MacOS.

[Screenshot]

3. To turn off Dark Mode, go to Word > Preferences > General > Personalize and select Turn off Dark Mode 

[Screenshot]
inclusive this section:

Personalize
● Turn off Dark Mode
○ Dark mode has a dark page color
○ Dark mode has a white page color

…

Set the page background color

Once Dark Mode has been turned on, you can toggle between the dark and light page background colors.

   1. In the ribbon, go to the View tab.

   2. Select Switch Modes to change the page background color. Word will remember the state of this toggle for future Dark Mode sessions.

[Screenshot]


Disable the dark page background

You can disable the dark page background in Dark Mode and keep the page light.

    Go to Word > Preferences > General > Personalize.

    Select Dark Mode has a white page color.

[Screenshot]

Check the appearance

Regardless of your Dark Mode settings, your document will print with the light mode page color. Also, your Dark Mode settings do not impact your collaborators, and Word will respect individual view preferences. To preview your document for printing and sharing, use the Switch Modes button to change the page background to light.  

…

</blockquote>
Comment 16 Commit Notification 2023-03-29 10:35:11 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5675937f7564fa5614f7be5aec0d7f20ba91d02c

Resolves tdf#152184 - Application color should follow system color

It will be available in 7.6.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 17 Heiko Tietze 2023-03-29 10:38:50 UTC
This patch removes the "Libreoffice Dark" scheme and introduces a switch that changes the Automatic colors from light to dark (user-defined colors are kept on switching). It also lists a "System Theme" entry which is assigned to light for now.
Comment 18 Heiko Tietze 2023-03-29 10:39:39 UTC
*** Bug 153334 has been marked as a duplicate of this bug. ***
Comment 19 John Mills 2023-03-29 11:53:38 UTC
Bug 153334 is for a related but different topic, that being the Canvas colour that is different from the UI in general.
Comment 20 V Stuart Foote 2023-03-31 14:12:36 UTC
The revision to Tools -> Options -> Application Colors dropping "LibreOffice Dark" example color scheme and expanding the Automatic color theme logic to provide a System Theme, Light, and Dark AC theme seems pretty functional.

Status WYSIWYG (i.e. light bg dark fg) for System Theme and Light, but with Dark can have a dark bg view.

@Heiko, was there still some additional effort needed so System Theme will toggle the automatics to Dark when an os/DE, e.g. macOS "Night Shift", low glare mode is activated? 

Or is that already in place with the System Theme value?  I can't tell on Windows where its flavor of "Night Light" affects the whole DE dropping the blue levels, it doesn't modify the application color themes in any sense, so I guess macOS only?


Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1b463f697405e64a03378fb38a32172c4d3c25e6
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 21 steve 2023-04-02 09:59:54 UTC
macOS specific follow up: https://bugs.documentfoundation.org/show_bug.cgi?id=154559
Comment 22 Heiko Tietze 2023-04-03 08:34:22 UTC
(In reply to V Stuart Foote from comment #20)
> @Heiko, was there still some additional effort needed so System Theme will
> toggle the automatics to Dark when an os/DE, e.g. macOS "Night Shift", low
> glare mode is activated? 

The "System Theme" is not yet implemented (no need for follow-up tickets IMO). It is hard-coded to light. Was hoping for support by Caolan ;-)

What has changed is the way light/dark is applied - now as modification to the Automatic color.
Comment 23 Commit Notification 2023-04-17 10:51:12 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/846e9a202b450445ede565c4f6a9a70954134438

Resolves tdf#152184 - App color follow system colors

It will be available in 7.6.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 24 steve 2023-04-19 16:28:35 UTC
*** Bug 154559 has been marked as a duplicate of this bug. ***
Comment 25 steve 2023-04-19 16:30:07 UTC
verified in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 61b41646c5a93ca24f2c9f143cdb0da2c9258989
CPU threads: 8; OS: Mac OS X 13.3.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

For macOS the default to follow system works as expected and UI changes instantly when changing ffrom dark to light or vice versa.

Thanks Heiko.
Comment 26 Sierk Bornemann 2023-04-19 17:25:04 UTC
Fix verified. Thanks, Heiko.

Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 61b41646c5a93ca24f2c9f143cdb0da2c9258989
CPU threads: 10; OS: Mac OS X 13.3.1; UI render: Skia/Metal; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
Comment 27 Stéphane Guillou (stragu) 2024-04-06 06:04:06 UTC
Added to the release notes:

https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F7.6&type=revision&diff=747819&oldid=747818

Please check if I missed something.

Follow-up issue for updates keeping the profile: bug 160513.