Created attachment 143034 [details] Windows 10 settings location to enable dark mode Currently, LibreOffice adopts an amazing dark mode when in Linux DE's. However, Microsoft is adding a dark mode to Windows 10. So it would be nice if LibreOffice could have a dark mode that would be turned on when enabling dark mode in Windows 10. Granted Windows 10 dark mode is still a work in progress and is limited to Microsoft native apps and UWP apps. A Microsoft blog post talking about Dark mode and how to enable it for UWP apps. https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/set-dark-mode A howtoGeek post talking about it and the new MacOS Mojave dark mode: https://www.howtogeek.com/354933/macos-mojaves-dark-mode-puts-windows-10s-to-shame/ However, Office 2016 has a great dark mode as well and it would be nice to see LO also having a dark mode. Right now there are several issues with dark mode in Windows 10. I added a few in the attachment
Created attachment 143036 [details] Libre Office 6.2Dev with firefox Persona Adwaita Dark Things that do not adopt a dark color: 1 - The Sidebar, 2 - The menus, 3 - The Tabbed bar, 4 - The toolbars, 5 - The application background. The only way to have a semblance of a dark mode in LibreOffice right now is: Select a Firefox theme. Adwaita Dark works best with the Colibre icons. This skins the toolbars, but not anything else as I'll show in the attachments.
Created attachment 143037 [details] Sidebar does not adopt Firefox theme color so it doesn't become dark like it does in dark modes in Linux.
Created attachment 143038 [details] Tabbed bar does not adopt a dark mode. It is still in development though.
Created attachment 143039 [details] Groupedbar adopts Firefox themes.
Created attachment 143040 [details] Microsoft Word Dark mode This is Microsoft Word 2016 dark mode. Notice how it adopts a not so dark grey in the Ribbon so that they don't have to change icon set. Same goes for Powerpoint and Excel.
This needs attention, but will depend on MS publishing API for accessing the theme colors for Desktop (i.e. non UWP use), likewise for Apple providing details for accessing them colors for Mojave builds. With those details, beleive we could map os theme details to LO GUI. Until then, this should just sit on a back burner as any implementation effort is premature.
I agree that this is lower on the priority list right now. However, this should be looked at for 6.2. In Build 2018 Microsoft revealed a lot of stuff. And Fluent Design support is coming for win32 apps, this means for LO as well. So I'm just drawing attention to this right now... Hopefully we don't have to select the dark colors of W10 because they really don't know how to design a proper dark theme. https://www.microsoft.com/en-us/microsoft-365/blog/2018/05/07/microsoft-365-empowers-developers-to-build-intelligent-apps-for-where-and-how-the-world-works/?irgwc=1&OCID=AID681541_aff_7593_159229&tduid=(ir_QRd0L-WqqUDI2QA1u1VxfxhfUkjTD3RT2ygWS80)(7593)(159229)()(UUwpUdUnU55829YYwYg)&irclickid=QRd0L-WqqUDI2QA1u1VxfxhfUkjTD3RT2ygWS80 This post details what's coming. It mentions the Fluent Design support. Furthermore, LO should add support for Sets (the OS-level tab system that Microsoft is implementing) immediately when it launches.
The Redstone 5 update will come in the Fall. Right when 6.2 development is occurring. If we react swiftly to this LibreOffice will draw a lot of attention from users. :) If we provide a dark theme and Set support in 6.2 a lot of people will want to try LO.
So, here's more information: UWP apps use XAML, a markup-based language that makes it easier to create user interfaces. XAML example: <Grid BorderBrush="Blue" BorderThickness="4"> <TextBox Text="Design with XAML" Margin="20" Padding="24,16"/> </Grid> https://docs.microsoft.com/en-us/windows/uwp/design/fluent-design-system/ UWP apps can use a light or dark color scheme: https://docs.microsoft.com/en-us/windows/uwp/design/style/color Theme can be changed by changing the requested theme property in the App.xaml file: <Application x:Class="App9.App" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="using:App9" RequestedTheme="Dark"> </Application> https://docs.microsoft.com/en-us/windows/uwp/design/style/color There's a loooot of stuff to fine tune there. This is relevant because, in Build 2018 they announced XAML islands for legay software like win32 apps, WPF and WinForms: https://developer.microsoft.com/en-us/events/build/content/announcing-uwp-xaml-islands?playlist=80d147e8-f3b0-4ca0-a96f-cfc8e80bec20 https://www.windowscentral.com/microsoft-giving-developers-access-fluent-design-win32-apps-and-more
(In reply to Pedro from comment #9) > ... > > This is relevant because, in Build 2018 they announced XAML islands for > legay software like win32 apps, WPF and WinForms: > > https://developer.microsoft.com/en-us/events/build/content/announcing-uwp- > xaml-islands?playlist=80d147e8-f3b0-4ca0-a96f-cfc8e80bec20 > > https://www.windowscentral.com/microsoft-giving-developers-access-fluent- > design-win32-apps-and-more That may be, but LibreOffice being cross platform we can not jump on every MS SDK twist. Do you somehow think Windows 7, Windows 8|8.1, or Windows 10 will support the XAML? I seriously doubt it... Meaning, if MS publishes a valid API for C++ development of win32 Desktop apps--only then can we adopt changes to MS theming to our internal handling of theme colors. And support all our Windows targets. This is a valid goal, but a lot remains to be seen with how MS implements.
(In reply to V Stuart Foote from comment #10) > That may be, but LibreOffice being cross platform we can not jump on every > MS SDK twist. Do you somehow think Windows 7, Windows 8|8.1, or Windows 10 > will support the XAML? I seriously doubt it... > > Meaning, if MS publishes a valid API for C++ development of win32 Desktop > apps--only then can we adopt changes to MS theming to our internal handling > of theme colors. And support all our Windows targets. > > This is a valid goal, but a lot remains to be seen with how MS implements. Agreed. I was just already gathering information for anyone that might be interested already. When I notice that there's more info about when this will be available for win32 desktop apps I'll immediately add it here.
*** Bug 118607 has been marked as a duplicate of this bug. ***
*** Bug 120725 has been marked as a duplicate of this bug. ***
*** Bug 120841 has been marked as a duplicate of this bug. ***
Don't think this topic needs more attention from UX. And besides, you need to CC needsUXEval to the ux-advice ML.
Chromium has managed to find the Registry key to parse for dark mode from a non-UWP program, although it’s a flaky method: https://chromium.googlesource.com/chromium/src/+/63e92830db63d5b7d03c245dda083cb4e7f33ea8%5E%21/
Complete the following article, you can do "dark mode." https://bugs.documentfoundation.org/show_bug.cgi?id=123544
Created attachment 149405 [details] Krita（https://krita.org/en/）（Please copy "Krita" directly, because "Krita" is "free software."）
"Dark mode", please do "black 100%".
Microsoft open-sourced their UWP calculator with an MIT license (it's based on their win32 calc.exe). https://www.zdnet.com/article/microsoft-is-open-sourcing-windows-calculator-on-github/ https://blogs.windows.com/buildingapps/2019/03/06/announcing-the-open-sourcing-of-windows-calculator/ Now it's possible to look at its code to see how to adopt Dark Mode for LibreOffice. https://github.com/Microsoft/calculator
*** Bug 124302 has been marked as a duplicate of this bug. ***
*** Bug 124969 has been marked as a duplicate of this bug. ***
Created attachment 153617 [details] science source of short sightedness is white background science source of short sightedness is white background so black background in displays is important in daily work for young people between 6 and 30.Less eye strain and better sleeping is good for all users with less white areas on the displays. looking to the sky daily is also important.
(In reply to paulystefan from comment #23) > looking to the sky daily is also important. And pray for developers to implement this :-)
*** Bug 129131 has been marked as a duplicate of this bug. ***
what I do not understand is why this enhancement request title is for Windows-specific only? I want this on my Ubuntu 19.19 too. Basically all Linux distros. Writing documents in white background suck my eyes ball. Changing the document property to mimic Windows-like Dark mode is painful especially when u have to share that document with your friends. I wonder, why this simple concept is not even implemented yet. I heard people use VS Code to write and last paste that document in LO Writer. That's sucks. There should be an option to makes things more comfortable. Like MS Word introduced.
(In reply to Prabesh432@gmail.com from comment #26) > what I do not understand is why this enhancement request title is for > Windows-specific only? > > I want this on my Ubuntu 19.19 too. Basically all Linux distros. Because for Ubuntu, another enhancement request would be titled "Add support for Ubuntu ... mode". And implementing that request would need other code changes (surprise, implementing platform-specific modes need platform-specific changes). And tracking those different goals in one issue is unreasonable (since bug tracker is a tool *for developers* to enable to track what is done and what needs to be done yet in a specific limited issue). And the only relation between those issues would be a "see also" link, and/or blocking a common meta bug.
(In reply to Mike Kaganski from comment #27) > Because for Ubuntu, another enhancement request... ...was created by Prabesh in bug 124969. Point is that "dark mode" means to more or less automatically adjust the configuration. You can make the app dark as hell manually, check tools > options > app colors (and tools > options > view > icon style for "breeze (dark)"). Consider also to save and share your dark app colors as extension (not sure if possible).
it seems like an enhancement to me. Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
*** Bug 130002 has been marked as a duplicate of this bug. ***
*** Bug 130335 has been marked as a duplicate of this bug. ***
Created attachment 159259 [details] german pdf print of geo article against short sightedness german pdf print of geo article against short sightedness for german developers see german geo article or this pdf. Night modus for working and reading is necessary with modified icons and tables in all versions of libreoffice not only the viewer also in macos, linux and windows
This is a big major feature for all users against strained eyes and critical for children and young users against short sightedness german scientist made the break throw. "However, black text on white paper heavily overstimulated retinal OFF pathways." "Therefore, reading white text from a black screen or tablet may be a way to inhibit myopia, while conventional black text on white background may stimulate myopia." Reading and Myopia: Contrast Polarity Matters Andrea C. Aleman, Min Wang & Frank Schaeffel In myopia the eye grows too long, generating poorly focused retinal images when people try to look at a distance. Myopia is tightly linked to the educational status and is on the rise worldwide. It is still not clear which kind of visual experience stimulates eye growth in children and students when they study. We propose a new and perhaps unexpected reason. Work in animal models has shown that selective activation of ON or OFF pathways has also selective effects on eye growth. This is likely to be true also in humans. Using custom-developed software to process video frames of the visual environment in realtime we quantified relative ON and OFF stimulus strengths. We found that ON and OFF inputs were largely balanced in natural environments. However, black text on white paper heavily overstimulated retinal OFF pathways. Conversely, white text on black paper overstimulated ON pathways. Using optical coherence tomography (OCT) in young human subjects, we found that the choroid, the heavily perfused layer behind the retina in the eye, becomes about 16 μm thinner in only one hour when subjects read black text on white background but about 10 μm thicker when they read white text from black background. Studies both in animal models and in humans have shown that thinner choroids are associated with myopia development and thicker choroids with myopia inhibition. Therefore, reading white text from a black screen or tablet may be a way to inhibit myopia, while conventional black text on white background may stimulate myopia.
(In reply to paulystefan from comment #32) > Created attachment 159259 [details] Please share the link to external sources.
The content of attachment 159259 [details] has been deleted
*** Bug 127776 has been marked as a duplicate of this bug. ***
*** Bug 134697 has been marked as a duplicate of this bug. ***
*** Bug 135293 has been marked as a duplicate of this bug. ***
*** Bug 85373 has been marked as a duplicate of this bug. ***
@Mike, Tomaž, * In comment 16, Adolfo had mentioned the 'AppsUseLightTheme' registry detection that the Chromium project had adopted. That looks to still be valid--but does not directly read the Windows UI theme. One of the other suggestions in a Stack Overflow thread [1] is that the Windows RT API does support use on normal win32 desktop programs. Looking at winrt API [2], example suggests with #include <winrt/Windows.UI.ViewManagement.h> using namespace winrt::Windows::UI::ViewManagement; calls to the winrt UISettings namespace expose the UWP and Desktop UI to c++ calls for normal win32 desktop apps. It would be Windows 10 only, but if not too problematic for building, it might expose the full Windows UI theming for LO to parse? Win7, Win8.1 would remain unsupported--and issues with HC mode toggle like bug 99116 would remain. =-ref-= [1] https://stackoverflow.com/questions/51334674/how-to-detect-windows-10-light-dark-mode-in-win32-application [2] https://docs.microsoft.com/en-us/uwp/api/Windows.UI.ViewManagement.UISettings?view=winrt-19041
*** Bug 137411 has been marked as a duplicate of this bug. ***
*** Bug 137414 has been marked as a duplicate of this bug. ***
https://bestosmosissystems.com/best-refrigerator-water-filter/
*** Bug 141199 has been marked as a duplicate of this bug. ***
As far as I see, there are 2 issues. The first is that it is currently not possible to enable or manually set the settings in LO to achieve nearly the same dark mode experience as on Linux. The second one would be to set these settings automaticly if windows dark mode is enabled. So wouldn't it make sense in a first step to allow to set colors for the currently not themable objects like tabbed ribon, title bar, sidebar, .., so that the users can manually setup the app to achieve a dark mode experience? If I am missing something, i.e. that this can allready be achieved, please correct me.
Get this shit fixed NOW! I mean it you guys. This is the single biggest objection I have to the program and am uninstalling the lot till it's fixed. Btw, at everypone else? You want to know why these passive aggresive dirtbags are posting against updating it? Because they're linux pussies. These guys failed at beating Micro$hit and they have a huge problem with anyone doing UI. This is what killed linux and they are butthurt about windows. There are programs like Adobe Photoshop with theming capabilty and dark modes. There is no excuses to not fix this IMMEDIATELY. UNINSTALLING. This is THREE FU***ING YEARS OLD, guys. This is disgusting.
Don't hide my comment. You are not taking criticism and are ignoring it. There are other bugs too. The font colour in the application colours for "General", do not change the "black", default font colour in the document. The font colour should be considered as default and active immediately on anything not set manually.
Also the colour selector square which is a biaxial spectrum next to the numerical colour objects on the left side, doesn't sometimes change when you drag the colour down on the linear spectrum column.
This is off-topic, so I apologize for causing clutter, but I would like to say that I as well would like to voice my support and request a dark mode for LibreOffice. I would like to abandon Microsoft Office due to privacy concerns, but the neglected and underdeveloped theming options in LO strain my eyes and are aesthetically unpleasing, in my opinion. If a proper dark mode is implemented, I would immediately switch over and recommend the same to everyone I know.
*** Bug 143981 has been marked as a duplicate of this bug. ***
*** Bug 144704 has been marked as a duplicate of this bug. ***
I started with a patch that exposes the systems colors under Tools > Options > Application Colors. It's kind of a workaround to the incorrectly read system colors. The idea is to be able to configure manually a dark mode - and eventually to make it customizable per extension. Now the discussion comes up whether this will be assumed as a solution given that users might expect an automatic switch from day to night, which wont be done with the patch. It does nothing but to list the system colors like menu color, dialog background etc. with the default values taken from whatever source (so the actual issue can be fixed by real developers). What do you think?
(In reply to Heiko Tietze from comment #52) > I started with a patch that exposes the systems colors under Tools > Options > > Application Colors. It's kind of a workaround to the incorrectly read > system colors. The idea is to be able to configure manually a dark mode - > and eventually to make it customizable per extension. > > Now the discussion comes up whether this will be assumed as a solution given > that users might expect an automatic switch from day to night, which wont be > done with the patch. It does nothing but to list the system colors like menu > color, dialog background etc. with the default values taken from whatever > source (so the actual issue can be fixed by real developers). > > What do you think? actually you did more with your work of defining a default "LibreOffice Dark" Application colors --> Color Scheme for bug 141986 And as noted there: https://bugs.documentfoundation.org/show_bug.cgi?id=141986#c14 "Either of two ways to address. One would be to implement support for UWP theming mechanism--a lot of native Windows code." Only that would "solve" the incorrectly read UWP system colors, though we'll need to keep track of HC mode behavior as well. "The other is to provide a full set of application colors touching all widgets of the UI." The problem remains (even with your https://gerrit.libreoffice.org/c/core/+/123548 patch) that too much of the UI is not exposed in the Application Colors color scheme to set our own LibreOffice managed defaults, and to block os/DE provided theme that overlays the "automatic" values.
(In reply to V Stuart Foote from comment #53) > > "Either of two ways to address. One would be to implement support for UWP > theming mechanism--a lot of native Windows code." > > Only that would "solve" the incorrectly read UWP system colors, though we'll > need to keep track of HC mode behavior as well. > Though another approach, as in comment 40, avoids the unsupportable UWP framework and uses winrt.UI.ViewManagement UIsettings for win32 calls to pickup the os/DE (XAML) theme support. Seems like this provides a functional alternative API providing full os/DE theme. But just of use for Windows 10 onward. [1] I think we can agree there will never be a win32 API for passing Windows WPF color theming. =-ref-= [1] https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-xaml-hosting-api
(In reply to V Stuart Foote from comment #54) > (In reply to V Stuart Foote from comment #53) > > > > "Either of two ways to address. One would be to implement support for UWP > > theming mechanism--a lot of native Windows code." > > > > Only that would "solve" the incorrectly read UWP system colors, though we'll > > need to keep track of HC mode behavior as well. > > > > Though another approach, as in comment 40, avoids the unsupportable UWP > framework and uses winrt.UI.ViewManagement UIsettings for win32 calls to > pickup the os/DE (XAML) theme support. Seems like this provides a functional > alternative API providing full os/DE theme. But just of use for Windows 10 > onward. [1] > > I think we can agree there will never be a win32 API for passing Windows WPF > color theming. > > =-ref-= > [1] > https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the- > xaml-hosting-api I think focusing on Windows 10 onwards for this is what makes sense. OS level support for dark themes was only introduced in W10. So it should be offered to W10 forward. Previous Windows versions are not supported by Microsoft anymore.
(In reply to V Stuart Foote from comment #54) > (In reply to V Stuart Foote from comment #53) > > > > "Either of two ways to address. One would be to implement support for UWP > > theming mechanism--a lot of native Windows code." > > > > Only that would "solve" the incorrectly read UWP system colors, though we'll > > need to keep track of HC mode behavior as well. > > > > Though another approach, as in comment 40, avoids the unsupportable UWP > framework and uses winrt.UI.ViewManagement UIsettings for win32 calls to > pickup the os/DE (XAML) theme support. Seems like this provides a functional > alternative API providing full os/DE theme. But just of use for Windows 10 > onward. [1] > > I think we can agree there will never be a win32 API for passing Windows WPF > color theming. > > =-ref-= > [1] > https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the- > xaml-hosting-api I can list about 5 or so non-UWP apps on my computer that support auto-dark mode from the system: Discord, Chrome, Firefox, MS Office, Paint.NET, Adobe Acrobat, and probably more I can't recall. I really cannot understand why you guys are making a big deal out of this.
Another non-UWP app that supports automatic dark mode in Windows 10 is the ftp client open source client WinSCP (GPLv3). Maybe it would be a good idea to get in contact with other open source software that managed to add this support to ask for pointers. Furthermore WinSCP is written in C++ so they might be able to help even.
Github repo of WinSCP https://github.com/winscp/winscp https://winscp.net/eng/index.php
Trying to read their code in Github. Is this the relevant bit? https://github.com/winscp/winscp/blob/master/source/windows/UserInterface.cpp line 376: void __fastcall ConfigureInterface() { int BidiModeFlag = AdjustLocaleFlag(LoadStr(BIDI_MODE), WinConfiguration->BidiModeOverride, false, bdRightToLeft, bdLeftToRight); Application->BiDiMode = static_cast<TBiDiMode>(BidiModeFlag); SetTBXSysParam(TSP_XPVISUALSTYLE, XPVS_AUTOMATIC); if (WinConfiguration != NULL) { UnicodeString Theme = WinConfiguration->UseDarkTheme() ? L"DarkOfficeXP" : L"OfficeXP"; if (!SameText(TBXCurrentTheme(), Theme)) { TBXSetTheme(Theme); } } And maybe in these next pages? https://github.com/winscp/winscp/blob/master/source/components/ThemePageControl.cpp https://github.com/winscp/winscp/blob/master/source/components/ThemePageControl.h
(In reply to Pedro from comment #59) > Trying to read their code in Github. Is this the relevant bit? > > https://github.com/winscp/winscp/blob/master/source/windows/UserInterface.cpp following that example would suggest that the relevant piece is: static int __fastcall SysDarkTheme(HKEY RootKey) at https://github.com/winscp/winscp/blob/master/source/windows/WinConfiguration.cpp#L2123
As Microsoft Windows users are an order of magnitude larger than Linux and MacOS combined in LibreOffice there should be feature parity in the desktop feature set mode between OS versions. As a primarily Windows user who donates on releases of LibreOffice I feel that my contributions are less valued than other OS users. The dark mode is also a usability feature as highlighted above and an expected feature in modern desktop applications. Emphasis should be made to remove this disparity for Windows users and improve the LibreOffice experience for >90% of the user base.
Created attachment 178847 [details] some partial effect With the experimental https://gerrit.libreoffice.org/c/core/+/131453 I get this screenshot. Menus are in dark mode too. So perhaps worth exploring further as there are some partial useful effects.
Wow, those are good news indeed. So it's possible to detect dark theme from Windows 10 and it changes elements?
Created attachment 178901 [details] screenshot of that approach Its not totally hopeless to go down a route like https://gerrit.libreoffice.org/c/core/+/131453 but it is not totally satisfactory either on trying to use the private windows apis and then bodge around with SetWindowTheme to get the handful of windows theme items that seem to work in that mode.
That seems perfect to me Caolan. Is it available on Master? How to enable it? I can test it out and provide you feedback.
There might be another issue though: the Tabbed bar. I doubt it will use the dark theme in Windows. That would probably need another set of patches to fix.
https://bugs.documentfoundation.org/show_bug.cgi?id=121877 Tabbed UIs do not use theme color - keeps the default application color This might be a challenge for dark mode support in Tabbed bar Caolan.
(In reply to Pedro from comment #65) > That seems perfect to me Caolan. > Is it available on Master? How to enable it? I can test it out and provide > you feedback. There isn't a pre-build. You can build it yourself with commit in question (but lot of work if you don't build LibreOffice on daily basis). I don't think there is no point of having this in Master already looking at the (current) commit message of https://gerrit.libreoffice.org/c/core/+/131453 Quote "Toggling from dark to light mode is detected, and getting some suitable colors for dark mode works. The titlebar will toggle into dark/light mode successfully. DrawThemeBackground does something sensible for buttons and scrollbar at least, comboboxes can be forced to work. SpinButtons are less successful. Menubar and toolbar just bodged to draw a solid backcolor." ---- It's simply not good enough at this point.
Yes, I understand. Don't want to push for something that is still not working properly to be included. I don't build on a daily basis, no...
(In reply to Telesto from comment #68) > > Quote > "Toggling from dark to light mode is detected, and getting some > suitable colors for dark mode works. > > The titlebar will toggle into dark/light mode successfully. > > DrawThemeBackground does something sensible for buttons and scrollbar at > least, comboboxes can be forced to work. SpinButtons are less > successful. Menubar and toolbar just bodged to draw a solid backcolor." > > ---- > It's simply not good enough at this point. I am sorry I don't get the point. If some UI elements have issues so why it prevent to be just experimental one? What kind of blocker is that? Should we wait for API change for Microsoft or should any further reengineering from LibO side?
Implementing this behind experimental mode would be a great way to gather more feedback and eve help from other devs, true.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a3f400886768bf95fbd8e6b236e11d7aac393b96 Related: tdf#118320 enable some windows dark theme support It will be available in 7.4.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 "tools, options, advanced, enable experimental features" enabled this partial very experimental "demo" is available with the caveats mentioned in the above commit message. Maybe it can help point people the right way towards a full solution and illustrate some of the code involved in how we do the windows themeing and color selection
Caolán, quite frankly this looks amazing already. The only real blocker I see is the Tabbed UI. There a couple of other minor issues that I'll open bug reports and append here. Another couple of suggestion can be done as enhancements: - Change Application color automatically to LibreOffice Dark when it toggles to Dark mode. - Change to Dark version of icon sets when Dark mode is activated. - Create option in the menu for the users to select Light or Dark mode by themselves (ex. user with light theme that wants dark mode in LibO or vice-versa)
(In reply to Caolán McNamara from comment #73) > With "tools, options, advanced, enable experimental features" enabled this > partial very experimental "demo" is available with the caveats mentioned in > the above commit message. Maybe it can help point people the right way > towards a full solution and illustrate some of the code involved in how we > do the windows themeing and color selection Yep, looking very promising. Setting Rizal's new Colibre Dark icons, and setting Application colors to the 'LibreOffice Dark' this last piece is doing a nice job of rendering in a Dark mode. With this configuration toolbars, menus and the SB deck all look great. And of the MUFFIN assemplages, every thing is pretty presentable except the 'Tabbed' and the 'Tabbed Compact', which have bg color issues for the UI area fills. This is a lot better than we were able to achieve using the os/DE passed theme details when an Assistive Technology 'HighContrast' theme is set; e.g. GreyEve and the forced Sifr icon theme. Looks like weere on the right track for Windows 10+, shame about the Tabbed UI--I know some folks will fuss. Thanks Caolán!
IMO (since I don't have the user data to back it up), the Tabbed UI is the most used in Windows because it is closer to the Ribbon UI from Microsoft Office. Thus, the only requirement to move this out of experimental would be to fix that bug.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c43c4a00089b1965c7ef69ef40c9e645dffc2e43 Related: tdf#118320 darkmode DrawThemeBackground doesn't work for tab bodies It will be available in 7.4.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.
As Caolán notes: "Its possible it makes more sense to not try and use the windows control drawings apis and just set some dark colors and draw with the old built-in vcl widget rendering or alternative." The uxtheme.dll ShouldAppsUseDarkMode() and SetPreferredAppMode() mechanism is functional if not the best documented API [1] for Win32 WDM development, but much better than other suggested approach of reading a DWORD value from the Windows Registry. But as the APIs are structured it means we can only provide DarkMode to Win 10 build 1904 (18362) or later (with things still settling out for changes in Win 11). It can not support Win 7.1, 8, 8.1 or earlier builds of Win 10. How much of an issue is that? And as Caolán suggests are we better served to round out the VCL based "Application Colors" dialog with the additional widgets that need UI color assignment? [1] https://github.com/microsoft/WindowsAppSDK/issues/41 =-off-topic-= Given that the vaunted "Tabbed UI" MUFFIN assemblages for the Notebook Bar are not native MS "Ribbon framework" code it remains wrong to put that forward as a work alike, especially as the standard UI toolbars, menus and dialogs supplemented with the Sidebar deck are the documented (and fully supported) LibreOffice work flows cfross-platform. Absent a major refactoring there, we do a disservice to users by steering them to the Tabbed UI--but that is off topic.
Created attachment 178972 [details] Bullets and numbering dialog Apparently the issue with the Tabbed UI is not restricted to the Tabbed UI itself but with tabbed dialogs themselves.
Created attachment 178973 [details] Paragraph dialog Mike Kaganski screenshot in LibreOffice Design Telegram channel showing Paragraph dialog after commit https://git.libreoffice.org/core/+/c43c4a00089b1965c7ef69ef40c9e645dffc2e43
--off-topic-- You don't do a great disservice in steering Windows users to a UI paradigm they are used to working with for the past 15 years and that they are confortable with. You have kids in high school that have known no other Office suite UI paradigm besides a tab-like UI. A great disservice would be to force them onto an UI paradigm they never saw in their lives using office suites if they want to use an open-source office suite. Well maybe they would just move to Only Office, which is another open source Office suite that is more agile in their development and that actually provides that familiar UI paradigm. I agree that it's a great disservice that there's always been so much outright hostility towards developing a well thought out Tabbed UI with a more appropriate code. If anyone wants to do it, they're welcome. Any talk of removing the Tabbed UI or disincentivize its use for Windows users, nor properly supporting is just downright hostility towards Windows users of LibreOffice. I welcome Caolán work towards this. If he has a Patreon account or something I would like to buy him lunch for this work.
Created attachment 178974 [details] Arrows to increase and decrease numbers The arrows highlighted in the red box do not obtain dark theme. This is minor compared to the issue with tabs in dialogs and the Tabbed UI.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/348407dfdf5fd41b99f5998463eb032128799555 Related: tdf#118320 tabitems appear as light in darkmode It will be available in 7.4.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/892ef6e8b6888b3029041ab150b409f81a5c31b0 Related: tdf#118320 let windows icon theme know when a dark theme is preferred It will be available in 7.4.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.
Created attachment 178993 [details] Make background of Tab body and Tab title same color and make Tab body border transparent (or give it same color as the other two) I would say these two things would clear up the Dark mode from Experimental to being supported: - Make background of Tab body and Tab title same color. - make Tab body border transparent (or give it same color as the other two). This would make the selected Tab body and Tab title seem continuous like the tabs look in Light mode.
It is just a matter of changing Tab body selected background color from #202020 to #666666. And to use also #666666 for the Tab body border color so that it disappears.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c51140847efa90897253011bd0382a32440d73e3 Related: tdf#118320 swap TILES_SELECTED and TILES_FOCUSED It will be available in 7.4.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/29c4d47161dab81971029717ce358de59f52f8c3 Related: tdf#118320 tabpane is too white in darkmode It will be available in 7.4.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.
@Caolán, had a test drive of today's Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: a997bd0e77d9721d55311dcfbd50fea802d801bd CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Dark icon theme toggle [1] is functioning. Can we do similar to toggle over to the "LibreOffice Dark" color scheme in 'Application Colors'? Although might need an expert config to be able to suppress for folks who still want a White canvas while in dark mode. Other than that, just the fg/bg colors on the MUFFIN NB Paragraph style previews for the Tabbed NB look to need a tweak for dark mode. But looks like you already got that [2]. This can probably come out of Experimental... =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/131843 [2] https://gerrit.libreoffice.org/c/core/+/131902
(In reply to V Stuart Foote from comment #89) > Can we do similar to toggle over to the "LibreOffice Dark" color scheme in > 'Application Colors'? The LibreOffice Dark might follow Breeze Dark but could also be some random pink colors. I don't see the system colors and the application colors being on the same level. Same idea coincidentally on Twitter https://twitter.com/nekohayo/status/1505374769176358914
(In reply to Heiko Tietze from comment #90) We need some change in how "automatic" colors are treated in the color schemes, trying hard to get some meaningful colors from system, including taking dark mode into account.
(In reply to V Stuart Foote from comment #89) > @Caolán, had a test drive of today's > Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: a997bd0e77d9721d55311dcfbd50fea802d801bd > CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: CL > > Dark icon theme toggle [1] is functioning. > > Can we do similar to toggle over to the "LibreOffice Dark" color scheme in > 'Application Colors'? > > Although might need an expert config to be able to suppress for folks who > still want a White canvas while in dark mode. > > Other than that, just the fg/bg colors on the MUFFIN NB Paragraph style > previews for the Tabbed NB look to need a tweak for dark mode. But looks > like you already got that [2]. > > This can probably come out of Experimental... > > =-ref-= > [1] https://gerrit.libreoffice.org/c/core/+/131843 > > [2] https://gerrit.libreoffice.org/c/core/+/131902 Where is the dark theme toggle located? Can't find it.
Created attachment 179033 [details] Tabs with latest commit These are the tabs after Caolán's latest commits. The white border surrounding the Tab body is gone. That immensely improved the visual of the dark mode and in itself to me, makes it suitable to be moved out of experimental. So I give my +1 to V Stuart Foote proposal. There's still no connection between Tab title and tab body, But I like the floating Tab titles and I kind of like highlight of the active Tab title? I'm conflicted. It looks good, but it's different from the look with Light mode so I would say consistency would be necessary. But I like this mode, so maybe change the Light mode to look like this. It reminds me of the tabs of the new Firefox UI. If they had rounded corners they would look awesome.
So active Tab title background is the same as inactive tab background. It's different from Tab body background. This seems like a conscious design decision from Caolán that might be dictated by limitations on what he can do or by a personal decision. Either way, I like it even if it's not the same as the Light tabbed UI.
Hi all,hi Caolán, This is starting to look really good,I would definitely use this now! Would the new tabs also be possible to implement in the Light mode? If it is possible then it would resolve the issue that I created in Bugzilla in 2018. https://bugs.documentfoundation.org/show_bug.cgi?id=122361 Thanks and very best regards, John
On a semi related note could I also ask is the header bar colour (in this case black)is an option that can be changed, I ask this because I think it would be really nice to see this reflect the colours of the constituent application, e.g. Blue for Witer, Green for Calc, red for Impress etc. Some colour would improve the look of what is a very grey application and make identification easier when you have many windows open at once. Cheers, John
Created attachment 179034 [details] White background on Slide background drop-down The background on Slide background drop-down in Standard toolbar view in Impress is light.
Created attachment 179035 [details] White background on display views Edit Modes White background also visible in Edit Modes of Display Views drop-down menu.
Created attachment 179036 [details] Column x Line numbers are still black (on black background) Column x Line numbers are still black (on black background) in Insert Table drop-down menu (both Impress and Writer). They should be White so that the numbers are readable (in the example the numbers should be 6*8).
(In reply to Pedro from comment #92) > Where is the dark theme toggle located? Can't find it. Not a manual action, the toggle is detected by Win10+ API called from dwmapi.dll and uxtheme.dll--ShouldAppsUseDarkMode() and SetPreferredAppMode()--mechanisms that Caolán picked up responding to how we set the Win10 Settings -> Colors -> "Choose your color" list box 'Light', 'Dark', or 'Custom'. Unfortunately we have no framework to consume a full XAML based UWP theme from the WDM. The old legacy GetSysColor() calls no longer suffice and were never parsed for UI color theme on the Windows builds. So while we now auto toggle the icon theme to Colibre Dark (thank you Caolán) we must still select the Tools -> Options -> Application Colors "LibreOffice Dark" color scheme--where a subset of the VCL widgets have colors set with defaults that appear OK in a Windows 10+ dark mode--but are not taken from the theme. Application color widgets set 'Automatic' are intended to pick up a color from os/DE theme, but those are not delivered to Windows builds, so they get set with defaults. User can customize either the LibreOffice or the LibreOffice Dark--or build/save their own UI color scheme. We just can't read it in automatically from any of the Windows builds.
Ah got it. Yes I noticed that it detects the theme option selected in Windows. I thought your comment referred to change the UI color from inside LibreOffice. My mistake then. Thank you for clarifying Stuart. :)
Created attachment 179282 [details] There's white area in document recovery Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 52ef78f4923283e6e52d575bec81985b031cb30b CPU threads: 8; OS: Windows 10.0 Build 22000; UI render: Skia/Vulkan; VCL: win Locale: id-ID (id_ID); UI: en-US Calc: CL
I've tested this feature with the daily master build of today (7.4 alpha) on Windows 11 22000.613 and it looks really good to me. Ok, it looks perfect :-). I haven't found any issues so far. Tested it with: Writer Calc Impress Thanks for the hard and long work on this issue.
Please make a wrap-up or rather close this one and open new ones for what's missing, unless already open. We have Meta for many issues, this one also deserved meta.
Agreed. And move it out of experimental.
I agree with Pedro here, what is remaining for this to be moved out of experimental now? What would be expected in a 'meta' ticket? Something like selectable light/dark or follow system theme?
*** Bug 148898 has been marked as a duplicate of this bug. ***
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/db4c4676b70bb5f9a1c169735e8fbe92b097a57b Related: tdf#118320 don't require experimental to be set anymore It will be available in 7.5.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.
I would wait to remove it out of experimental because there's those multiple minor issues that were reported by me and Ryzal that should be addressed before the 7.5.0 release. Unless those are worked on before the release?
(In reply to Pedro from comment #109) Moving out of experimental early enough in the release cycle is fine; it's always possible to undo that, but this way, it gets more testing.
Created attachment 181883 [details] In windows 11 color highlight is too light and up and down buttons still not themed. Additional issues in Windows 11 that should be addressed before 7.5.0 move out of experimental.
Thank you for clarifying this for me Mike. :)
*** Bug 150521 has been marked as a duplicate of this bug. ***
I'm adding Windows Dark Mode meta as bug 150915. I kindly ask reporters of duplicate bugs to verify that their requests were resolved, if not please set bug from duplicate to Unconfirmed and to block bug 150915. Stuart, you are welcome to write a wrarp up there. I think it's safe to close this one now with huge thanks to Caolán.
*** Bug 155653 has been marked as a duplicate of this bug. ***
I'm adding Windows Dark Mode meta as bug 150915 <a href="https://driftboss3d.io">Drift Boss</a> . y that their requests were resolved, if not please set bug from duplicate to Unconfirmed and to block bug 150915.