Currently the dark theme/mode is a common feature in applications, even as a system wide feature, which helps reduce the annoyance of light colors in dark environments.
Currently LibreOffice doesn't have a native dark theme/mode and there are only tutorials to customize some colors of the application or in gnu/linux, use the dark theme used in the system, however, this brings a series of problems as it is not always well adapted to the Libreoffice interface elements. A quick bugzilla search shows a series of related reports.
Additionally, LibreOffice has application icons adapted for dark themes, in a way it shows interest in supporting them.
Steps to Reproduce:
User Profile Reset: No
Ideally, LibreOffice should show the same themes on all operating systems, which helps to have a certain consistency, without giving up certain integration elements but ensuring the correct display of the user interface elements.
On the other hand, in the particular case of gnu/linux, perhaps a setting that allows deactivating the dark theme regardless of the selected global theme, would help an occasional person to solve the particular problem without deactivating the global theme.
Agree, this is optimization in addition to the os/DE provided theme response--mode would manifest as a Color Scheme in the Tools -> Options -> Application Colors to supplement the current default "LibreOffice" color scheme with a "LibreOffice Dark" color scheme.
os/DE obviously would still control, but this would augment/expand the UI elements now being controlled by theme to improve a dark mode experience.
Application colors for default UI elements, including those that now are set light and bypass theme controls, would still be automatic to respond to os/DE theme--but the defaults would need to be contrast adjusted "light on dark", rather than current "dark on light".
Not a new idea and likely requested many times. I'm all in for this additional set of application colors. See also bug 141566 about a dark background for Basic.
Created attachment 171611 [details]
1st patch applied
Patch at https://gerrit.libreoffice.org/c/core/+/115042; most/all? settings for "Text Documents" are ignored in Writer. Colors for General taken from Standard palette for nice naming and Breeze Dark for the links (which are ignored in Writer) https://github.com/KDE/breeze/blob/master/colors/BreezeDark.colors
It's easyhackable; feel free to amend my patch
It missed proper l10n for "Dark".
@Heiko, good start. Didn't we recently do away with the need to decimal code the colors? So, the "2364108" could/should be "2412CC", or was that just Dante for the sm modules...
Also, in the rendering of your 1st patch, attachment 171611 [details], the comments are laid out on a non-theme controlled frame so onto that hardcoded lightgray value.
Also, the Table cells are an uncontrolled white background, with a balck fg font--that's an issue.
Likewise the Chart axis labeling seems uncontrolled black fg font.
I'm sure there are other places the os/DE theme and current Application Colors do not touch--and will need some dev attention more than just a new set of colors defined in UI.xcu
Some logic to control the icon themes (based on fg / bg colors) of the ColorTheme as well?
(In reply to V Stuart Foote from comment #4)
> comments are laid out on a non-theme controlled frame so onto that hardcoded
> lightgray value.
That's a major showstopper for dark themes.
> Also, the Table cells are an uncontrolled white background
I'm using formatted dummy text  and the table is formatted by "Elegant" which has a cell background defined. Similar issue as in text becoming "0" due to the number format or the fact that fonts are always overwritten by Liberation Sans or Serif.
> Likewise the Chart axis labeling seems uncontrolled black fg font.
Haven't changed the Chart colors.
> Some logic to control the icon themes (based on fg / bg colors) of the
> ColorTheme as well?
Would appreciate if we have a switch to "darken" the colors and "invert" the icons. This approach with a second color set is never working properly, I'm afraid.
Hi! I think the dark theme should focus on UI elements and not on the document background in Calc, Writer and Impress/Draw.
The reason is that, even on a dark theme, many users will be interested in using a white background in Writer documents, because it's the way the document will later be published (in PDF) or printed in a white sheet of paper. Hence, having a white background allows the user to better see how the document will be rendered when exported/printed.
Just to illustrate, dark theme on MS Office still uses white background for documents:
For example, in Bug 141566 having a color for the Basic Editor (following system theme) makes sense because the Basic code is not meant to be printed or exported to PDF, it is just programming code.
But having dark background for documents may end up annoying some users who'll want to stick with white background even on a dark theme.
What we could do is add two new themes. Instead of just one dark theme, we could add:
- Dark Theme with White Document Background
- Dark Theme with Dark Document Background (which is what Heiko has already uploaded)
(In reply to Rafael Lima from comment #6)
> Hi! I think the dark theme should focus on UI elements and not on the
> document background in Calc, Writer and Impress/Draw.
> The reason is that, even on a dark theme, many users will be interested in
> using a white background in Writer documents, because it's the way the
> document will later be published (in PDF) or printed in a white sheet of
> paper. Hence, having a white background allows the user to better see how
> the document will be rendered when exported/printed.
> Just to illustrate, dark theme on MS Office still uses white background for
> For example, in Bug 141566 having a color for the Basic Editor (following
> system theme) makes sense because the Basic code is not meant to be printed
> or exported to PDF, it is just programming code.
> But having dark background for documents may end up annoying some users
> who'll want to stick with white background even on a dark theme.
Most folks who adopt a 'dark mode' are looking to reduce the heat/glare that a white page background causes, they are less concerned with final print format/appearance. So retaining the page, sheet, slide or drawing canvas as a white blob when the rest of the UI is in dark mode doesn't make a whole lot of sense. Maybe a toggle to check WYSIWYG for layout--but if doing an additional set of application color defaults for 'dark mode' then the full UI including the canvas needs to be included.
This is even more helpful for Windows users where there is no support for the UWP theme mechanisim. Where a full set of alternative LibreOFfice application colors is needed to deliver something that won't burn out your eyeballs.
> What we could do is add two new themes. Instead of just one dark theme, we
> could add:
> - Dark Theme with White Document Background
> - Dark Theme with Dark Document Background (which is what Heiko has already
Sure, it is just an additional set of .xcu stanzas. But key is a bit of dev effort to getting all elements of the UI to respond fully and as needed expand the values recorded to Application colors.
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":
Resolves tdf#141986, related tdf#141566 - Dark theme
It will be available in 7.2.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:
Affected users are encouraged to test the fix and report feedback.
I would expect a simple switch that inverts the color brightness for dark themes- not a full set of colors. But for testing purpose I submitted the patch.
Some follow-up issues:
bug 142115: Color of comments bar should follow the document canvas color
bug 142116: Application color Field Shading not respected
bug 142118: Application color AutoSpellcheck not applied immediately
bug 142120: Application color for CalcText not respected for cells with line breaks
bug 142121: Cell focus rectangle must not use font color
bug 142122: Applying changes to application color must not save it
Closing this one now.
Created attachment 171751 [details]
LibreOffice Dark color theme on Windows with HC based GreyEve theme
So, should know that Windows WDM does not provide usable theme details exepct when using a theme classified HighContrast. So current UWP based Dark Mode on Windows remains unsupported in LibreOffice.
Default colors of the new LibreOffice Dark preset theme are helpful.
Here I'm attaching a clip with the only functional on LibreOffice Windows 10 Dark Theme, the High Contrast based GreyEve Theme v2.1
Note the toggle to Sifr icons. But it is a bit more effective than the existing LibreOffic app color theme.
Created attachment 171752 [details]
LibreOffice Dark color theme on Windows with UWP "Dark" mode
So folks can understand the issue with Microsoft's UWP Dark mode, this clip shows the new LibreOffice Dark application colors on a Windows 10 system with Dark mode set.
LibreOffice can not consume the UWP based theming that would control the Automatic values of the Application Colors panel.
Isn't this bug 118320
(In reply to Heiko Tietze from comment #13)
> Isn't this bug 118320
Yes, and *either* of two ways to address. One would be to implement support for UWP themeing mechanisim--a lot of native Windows code.
The other is to provide a full set of aplication colors touching all widgets of the UI.
The new "LibreOffice Dark" theme covers maybe 2/3 of what would be needed for Windows (and frankly all other platforms) with fixed defaults and no "automatic" handling of os/DE theme.
That is, in addition to defining a full set of defaults for the bi-modal (normal/dark) themes, provide a toggle to block os/DE theme parsing and then use either of the LibreOffce application color themes from the Tools -> Options -> Application Colors panel.
No additional Windows Display Manager/UWP refactoring, nor macOS NSview and NScolor, native code would be needed at that point--the LibreOffice theme(s) with good defaults would suffice.
(In reply to V Stuart Foote from comment #7)
> (In reply to Rafael Lima from comment #6)
> Most folks who adopt a 'dark mode' are looking to reduce the heat/glare that
> a white page background causes, they are less concerned with final print
> format/appearance. So retaining the page, sheet, slide or drawing canvas as
> a white blob when the rest of the UI is in dark mode doesn't make a whole
> lot of sense. Maybe a toggle to check WYSIWYG for layout--but if doing an
> additional set of application color defaults for 'dark mode' then the full
> UI including the canvas needs to be included.
I think that the concept of "dark theme" and "dark mode" must be differentiated, the first one focuses on using a dark theme in UI elements according to the preferences of the OS/DE but that doesn't affect the content of the document, so that the visualization of this is commonly expected. which you see (normal/print mode in Writer and edit mode in Impress). Another thing would be the web mode in Writer or outline mode in Impress for example. As a consideration, other office suites work the same way (not inverting the color of the content) as OnlyOffice, Sofmaker Office, WPS, MS Office, etc.
I think that inverting colors or using darker colors typical of the dark mode as the one that affects web content is more aimed at consuming "final products" and not editing them (leaving aside the workflow of a developer when writing code or power user using markup language). Inverting colors or using dark colors can be a separate and complementary approach. In my personal case I would not like to see inverted colors when I write a document, but I do when I make revisions and I only have to leave comments, especially at night when using LibO.