https://bugs.documentfoundation.org/show_bug.cgi?id=149611#c0
Microsoft 365 Office’s Word does this (at least if the text colour is set to Automatic).
1 Like
I am not sure to understand the request in the bug report. I agree that system theme should be forwarded as much as possible into windows decoration and widgets because they are “integrated” in the OS and its libraries. But a document is not part of the OS; it is a different, independent “object” related to printed material paradigm. A sheet of paper can’t inherit OS background; its colour is determined by the stationery manufacturer.
Requesting that OS theme applies to the text you’re writing is not “portable”. Your document will not be rendered the same on another computer. If you prefer to see white text on black page background and you consider this is the nominal state for your document, define it through a collection of styles stored in a template. The template can be reused across documents. And if styles are carefully designed in a hierarchical way, it is easy to change only a couple of them to fit someone else’s tastes.
There are people who expect the following:
- The system is set to a light theme, so LO should use a light theme too.
- The system is set to a dark theme (or dark mode), so LO should use a dark theme too.
It’s not about changing styles. Those people want that everything is dark (including the page) if using a dark theme.
Apparently M$ word does that…
Here’s what would happen as far as I understand:
- If dark mode is activated, the entire ui gets dark.
- The page gets dark, black fonts will be displayed white and colors might change (e.g. red becomes another red coloring) for readability.
- If you print the file or turn off dark theme, everything gets reversed to the normal / standard ui and looks (dark sheet becomes white again, white text becomes black…)
People claim that it’s an accessability issue, claiming it causes eye strain if looking at a white page at night.
Personally I don’t understand how the dark theme is supposed to work if you use any colors in your document. Dark mode would change the colors so that they are more readable on black text. But that makes actual theming for a white page quite difficult / impossible, doesn’t it?
However, there also seem to be a lot of people whoe just write text without using colors (i.e. standard black text on white background). For those the dark theme wouldn’t cause any problems and it may help them with eye strain.
If you have an android phone you may have a notes app that changes to light and dark themes according to your system theme. Any note color will be changed, as well as text color etc. This might help you to understand what they want.
EDIT: You can go to this link and look at the picture. Compare it to the picture from the bug report. As you can see, M$ uses a black page too if a dark theme is set (not just ui) but LO only changes the ui color. That is what those people dislike.
1 Like
I wonder if the eye strain complaint is not just a matter of correctly adjusting one’s screen. Present day LCD screens are way too bright causing a loss of contrast in light shades (many of them look roughly the same).
I had a hard time calibrating my screens so that I have correct shading on all three channels. Remember that “brightness” control defines your black level, “contrast” the white level and gamma allows you to balance intermediate levels. Do this on R, G and B channels separately, then on gray scale.
If you have no photometer probe, this Wikipedia page has several scales which could help you for a first attempt.
With correctly adjusted screens I never had issue with eye strain.
2 Likes
I don’t care about the style of my document. I use .odt for its advanced embedding and data exposure (databases to tables) features, not typefaces and colouration. I’d rather it were more like .md or .txt in that regard.
https://bugs.documentfoundation.org/show_bug.cgi?id=149611#c4
No, although it is a significant improvement.
In LibreOffice 7.6.0.3 the default is for the UI and the page to be the same as Windows colour scheme. If Windows is dark, so is LibreOffice UI and page. You can still set either to light or dark, if you want.
Then you must add that to your bug report.
That the Automatic selection in Application Colours doesn’t change the page colour as it should
1 Like
I downloaded the daily build from 2023-Aug-27 and am using the following system inside of a virtual box:
OS: Debian GNU/Linux 12 (bookworm) 64-bit
Windowing system: Wayland
DE: Gnome
My libreoffice info from help > about:
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e16e84c44fc7517529c8a183fbd8f97c0c3e380e
CPU threads: 4;
OS: Linux 6.1;
UI render: default;
VCL: gtk3
Locale: en-US (en_US.UTF-8);
UI: en-US
Calc: threaded
I had to go and change “automatic” from “light” (default) to “system theme” as @EarnestAl described in the picture above (see this link to go to his comment)
Here’s what it looks like in light mode:
And here what it looks like in dark mode:
In my understanding that does solve your problem, right @rokejulianlockhart? If not, then you should go to the bug report and state what exactly isn’t the way you want it.
If it does solve your problem, you might have to wait to get this version officially released.
1 Like
-
[ ] I’ll mark How to make Writer page adhere to system/LO theme? - #13 by TheSmallest as the solution when/if that version gets to me and works in the manner described.
149611 – Allow the page to adhere to the theme of the system.
Can you confirm that the behaviour is actually different to the version I quoted, @TheSmallest? I can’t easily test anything newer than what I’m using currently. If the listed version is indeed as I describe, and the newer version as you describe, set this as resolved. Better defaults would be a separate issue.
Tested a few things, see bug report.
Short answer:
- If you use gnome with the latest daily LO build: it works.
- If you use kde plasma with the latest daily LO build: it doesn’t work.
1 Like
Update: This has been solved now in LO 24.2.0.0.alpha0+ (daily build from 2023-Sep-03).
For additional info see bug report comment 17.
1 Like