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
Caolán: as tdf#152183, thought you might be interested in this one since it concerns dark mode in macOS
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.
*** Bug 152270 has been marked as a duplicate of this bug. ***
*** Bug 152221 has been marked as a duplicate of this bug. ***
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.
Sill needs UX-Advise, no agreement on how or if to address => UNCONFIRMED
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.
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>
(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.
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.
This is not limited to macOS, setting OS to all, since at least also windows is affected.
*** Bug 153329 has been marked as a duplicate of this bug. ***
*** Bug 153334 has been marked as a duplicate of this bug. ***
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 ***
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>
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.
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.
Bug 153334 is for a related but different topic, that being the Canvas colour that is different from the UI in general.
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
macOS specific follow up: https://bugs.documentfoundation.org/show_bug.cgi?id=154559
(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.
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.
*** Bug 154559 has been marked as a duplicate of this bug. ***
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.
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
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.