Created attachment 184165 [details] Active selections from the tabbed menu bar have light blue backgrond which makes the white icon alsmost invisible Dark Mode on Windows 11 shows lightblue border for active items in the tabbed menu bar which makes icons and it's text almost invisible as those are mostly white itself. The border collor of the active its (screenhot attached) maybe should have a dark fill with the collor of the tabbed menu bar itself (or slightly lighter). That what an active item has the light blueborder with a dark fill which makes the white icon better visible.
Version: 7.5.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 3aca23eec42e9d6fbe57071d7633ae1fc4bc5fcc CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL threaded
Can't reproduce with Windows 10 and default dark mode colours: Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded
Same issue in 7.5.0.2. Version: 7.5.0.2 (X86_64) / LibreOffice Community Build ID: c0dd1bc3f1a385d110b88e26ece634da94921f58 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL threaded
Marking as new as I can see the same in Rizal's post: https://libreofficemaster.blogspot.com/2022/03/libreoffice-dark-mode-on-windows.html
It seems this is a bug in Windows 11. Notepad++ also faced this issue and they come with a workaround (the text and image underneath is automatically inverted upon selection): issue: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/10510 workaround: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/10685 I can confirm this bug is still present in the latest beta insider of Windows 11.
Created attachment 185222 [details] Notepad++ workaroud
*** Bug 153511 has been marked as a duplicate of this bug. ***
(In reply to dulven123 from comment #5) > It seems this is a bug in Windows 11. Notepad++ also faced this issue and > they come with a workaround (the text and image underneath is automatically > inverted upon selection): > issue: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/10510 > workaround: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/10685 > > I can confirm this bug is still present in the latest beta insider of > Windows 11. Caolán, what do you think? Not our bug? Can we do a similar workaround?
Created attachment 185297 [details] Windows 10 for reference Windows 10 looks ok AFAICS. Apparently my Windows box is not eligible for upgrade to Windows 11 so someone else will have to investigate if this is still a problem and what the solution might be.
*** Bug 155392 has been marked as a duplicate of this bug. ***
Duplicate bug 155392 tells us it is still current in 7.5.3.2.
Can confirm that this is still an issue in 7.6.0.0.alpha1. Version: 7.6.0.0.alpha1 (X86_64) / LibreOffice Community Build ID: 9366f83c88fc93d40ea0c0035508f24ad5dcb144 CPU threads: 24; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded ^ Again, it says that I'm on Win10, but I'm on Win11 22H2.
(In reply to haxellio from comment #12) > Again, it says that I'm on Win10, but I'm on Win11 22H2. We know you are on Windows 11. Any build 22621 is Win11, not Win10--blame Microsoft's SDK not keeping up with MS Marketing. https://en.wikipedia.org/wiki/Windows_10_version_history https://en.wikipedia.org/wiki/Windows_11_version_history
*** Bug 155499 has been marked as a duplicate of this bug. ***
The Notebook Bar UIs were tweaked for bug 152454 for Win11 to not use Buttons for the tabs [1] and set better colors [2]. To support Win11 dark theme, something similar may be needed to render selected toggles for button widgets bcz MSSTYLES handling at Win11 muddles fg and bg assignment. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/144046 [2] https://gerrit.libreoffice.org/c/core/+/144045
I confirm, the error is still in version 7.5.3 and 7.6.0.0.alpha1 of libreoffice in Windows 11, I don't know if the same error is present in other operating systems.
Some more details on this bug from me: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1598660527 Response from Explorer++ developer: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1600267784 Basically, this bug is due to a change within aero.msstyles theme file since the very first Windows 11 release. They only changed BUTTON resource for some reason to this terrible light/bright blue color. They never changed SPLITBUTTON resource though which is odd. The bug does not affect users who use a custom msstyles theme though, which of course is unsupported by Microsoft. It only affects default Aero theme. This seems to affect programs that utilize win32-darkmode functionality, such as Notepad++, Explorer++, LibreOffice and possibly more that I am not aware of. I believe one of the only solutions at the moment would be custom drawing of each button.
(In reply to WildByDesign from comment #17) > ... > I believe one of the only solutions at the moment would be custom drawing of > each button. But it also looks like a Win11 work around is possible for LibreOffice (awaiting some MS movement to fix their issue with the Win11 image color in aero.theme) as Don HO did for Notepad++ issue 10510 and and pull 10685 [1][2] with: https://github.com/notepad-plus-plus/notepad-plus-plus/commit/5d086f93a80d275fcc5e4047ae49c614680a7e5b testing for Windows 11 build, to reverse the fg color of the button text when hot. Can't fix the image color/transparency issue--but can allow the icon to show with some contrast. =-ref-= [1] Notepad++ https://github.com/notepad-plus-plus/notepad-plus-plus/issues/10510 [2] Notepad++ https://github.com/notepad-plus-plus/notepad-plus-plus/pull/10685/commits
Within the past week, there has been 4 users on the LibreOffice subreddit who brought this exact issue up: - https://www.reddit.com/r/libreoffice/comments/14oze66/just_got_libreoffice_and_ive_some_questions/jqjdjat/ - https://www.reddit.com/r/libreoffice/comments/14osggh/dark_mode_light_mode_either_way_any_toggle/jqlaot0/ - https://www.reddit.com/r/libreoffice/comments/14ql72o/how_do_i_fix_this_bad_contrasting_when_in_dark/jqotku9/ (The first topic was even a very first-time user of LibreOffice—so probably not a great first impression!) If there was 4 complaints within a week, I'm suspecting there are many other silent Windows 11 users out there being hit by this issue as well. No pressure though. :)
Also brought up on ask.LO: https://ask.libreoffice.org/t/cannot-read-highlighted-option-text-in-light-mode/88474
Stuart, any reason why you removed the "accessibility" keyword? To me, this is clearly an issue that affects accessibility – see for example first-hand user account here: https://www.reddit.com/r/libreoffice/comments/14oze66 I've added it back but please let me know if it wasn't an error. Michael, adding you to CC in case you are interested.
(In reply to Stéphane Guillou (stragu) from comment #21) > Stuart, any reason why you removed the "accessibility" keyword? To me, this > is clearly an issue that affects accessibility – see for example first-hand > user account here: https://www.reddit.com/r/libreoffice/comments/14oze66 > > I've added it back but please let me know if it wasn't an error. > > Michael, adding you to CC in case you are interested. Don't see it as an accessibility issue. Believe we handle (consume the os/DE color scheme) for the Win11 Ease-of-Access "Contrast themes" when set active on os/DE for all four of the Win11 HC themes: "Aquatic" "Desert" "Dusk" "Night Sky" The buggy button handling does not affect those Win11 HC themes (msstyles) and our AT tools perform as intended. Instead, this is a simple issue in a MS default color theme for buttons--Microsoft picked a stinker bg fill color for Win11 activated button. We can possibly perform an inversion of button fg / bg, but the current bg color comes from the os/DE theme. The a11y themes which now also follow respective os/DE theme aren't affected--they have a theme specific button handling.
(In reply to WildByDesign from comment #17) > Basically, this bug is due to a change within aero.msstyles theme file since > the very first Windows 11 release. They only changed BUTTON resource for > some reason to this terrible light/bright blue color. They never changed > SPLITBUTTON resource though which is odd. I don't have Windows 11 to test myself, but I'm wondering whether this been reported to Microsoft? Maybe emphasizing the problem on their end might help to increase importance there as well, and at least ideally this should be fixed where the actual root cause is...
(In reply to Michael Weghorn from comment #23) > I don't have Windows 11 to test myself, but I'm wondering whether this been > reported to Microsoft? Maybe emphasizing the problem on their end might help > to increase importance there as well, and at least ideally this should be > fixed where the actual root cause is... That's a good question but unfortunately I don't know the answer. I honestly don't even know how to find out if it's been reported before or how exactly to report it properly. This bug has been around since the very first public build (22000) of Windows 11. I have done some more research into this aero.msstyles bug since my last comment in this LibreOffice bug thread. Apparently, the theme file does contain the correct dark mode BUTTON resource but for some reason it is not being utilized and instead pulls the light mode BUTTON resource. You can see my more recent comment (and msstyles resource comparison image) on the Explorer++ Github page: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1617115230 In that same comment, I ask the developer how someone should properly report this to Microsoft. He would have a better understanding of what is actually happening with the code and under the surface with the operating system. I haven't got a response back yet.
(In reply to WildByDesign from comment #24) > In that same comment, I ask the developer how someone should properly report > this to Microsoft. He would have a better understanding of what is actually > happening with the code and under the surface with the operating system. I > haven't got a response back yet. Great, thanks a lot! I see that the issue has been reported to Microsoft now, as this comment mentions: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1657405123 (I can't the link to the Microsoft Feedback Hub provided there to check the actual status without having to install an extra app, though...)
The developer of Explorer++, David Erceg, who has a good understanding of the win32-darkmode implementations has followed up with a nicely detailed response. Link: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1666308914 Some of my takeaways from the response: - The issue is not likely specific to the aero.msstyles theme resource file itself, but more likely issues within the dark mode API (within Windows) that pulls data from the theme resource file. - "Even with the use of the undocumented APIs and classes from aero.msstyles, partially or fully drawing controls is still necessary to achieve a cohesive result." - The fact that win32-darkmode consists of undocumented APIs, these issues would be unsupported and extremely unlikely that Microsoft would ever fix these issues. Since Microsoft requires installing an app just to vote for the issue to be fixed, that makes it much more difficult to bring attention to the issue. There is often issues in Windows which get 10s of thousands of votes before it puts enough pressure on Microsoft to implement whatever fix or feature update. I don't hold much hope on this issue, unfortunately. Also, from my own personal opinion, that workaround that Notepad++ which simply inverts the color, is still quite terrible. That workaround would still be bad for any users with vision problems. Also it's quite jarring regardless from a visual perspective. I created an msstyles alternative (https://github.com/WildByDesign/Aero.msstyles-win32-darkmode) which is essentially default aero.msstyles file with the one and only change to it being swapping the terrible bright blue highlight to a proper dark mode highlight for toolbar icons. Yet still, getting users to install a separate aero.msstyles theme is not a great workaround either. I created this mostly with vision impaired users in mind. I still believe that custom drawing the toolbar icons is the only proper way to fix this bug and it seems to be what David Erceg (Explorer++ dev) is also suggesting.
*** Bug 157017 has been marked as a duplicate of this bug. ***
Removing "notebook bar and sidebar UI" from the summary as https://libreofficemaster.blogspot.com/2022/03/libreoffice-dark-mode-on-windows.html shows it in the standard toolbars as well.
*** Bug 157257 has been marked as a duplicate of this bug. ***
(In reply to Stéphane Guillou (stragu) from comment #29) > *** Bug 157257 has been marked as a duplicate of this bug. *** Thanks (ou "merci", au vu du prénom) Stéphane and sorry for the duplicate. I searched for a long time but didn't find this bug 152534. Happy to not be the only one having it and seeing the problem!
I can confirm that (In reply to WildByDesign from comment #26) > The developer of Explorer++, David Erceg, who has a good understanding of > the win32-darkmode implementations has followed up with a nicely detailed > response. > > Link: > https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1666308914 > > Some of my takeaways from the response: > > - The issue is not likely specific to the aero.msstyles theme resource file > itself, but more likely issues within the dark mode API (within Windows) > that pulls data from the theme resource file. > > - "Even with the use of the undocumented APIs and classes from > aero.msstyles, partially or fully drawing controls is still necessary to > achieve a cohesive result." > > - The fact that win32-darkmode consists of undocumented APIs, these issues > would be unsupported and extremely unlikely that Microsoft would ever fix > these issues. > > Since Microsoft requires installing an app just to vote for the issue to be > fixed, that makes it much more difficult to bring attention to the issue. > There is often issues in Windows which get 10s of thousands of votes before > it puts enough pressure on Microsoft to implement whatever fix or feature > update. I don't hold much hope on this issue, unfortunately. > > Also, from my own personal opinion, that workaround that Notepad++ which > simply inverts the color, is still quite terrible. That workaround would > still be bad for any users with vision problems. Also it's quite jarring > regardless from a visual perspective. > > I created an msstyles alternative > (https://github.com/WildByDesign/Aero.msstyles-win32-darkmode) which is > essentially default aero.msstyles file with the one and only change to it > being swapping the terrible bright blue highlight to a proper dark mode > highlight for toolbar icons. Yet still, getting users to install a separate > aero.msstyles theme is not a great workaround either. I created this mostly > with vision impaired users in mind. > > I still believe that custom drawing the toolbar icons is the only proper way > to fix this bug and it seems to be what David Erceg (Explorer++ dev) is also > suggesting. Thanks WildByDesign, your solution on GitHub works great! I'm not sure what the best place would be, but it'd be great if this was also linked in the official support somewhere or anywhere more obvious -- it the only way I've found to make Windows 11 dark mode usable and it took some *finding*.
And there was 1 more completely-new-to-LibreOffice Windows 11 user who reported this on the subreddit: - https://www.reddit.com/r/libreoffice/comments/182siys/new_to_lo_two_issues_so_far_windows/
*** Bug 158864 has been marked as a duplicate of this bug. ***
Just to reiterate observation of comment 22, the a11y Win11 "Contrast themes" are not affected by this MS issue with unsupported split button in win32 aero.msstyles Using the provided Win11 "Aquatic", "Desert", "Dusk", or "Night sky" contrast themes receive button color assignments that keep sufficient contrast. =-testing-= Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
*** Bug 159504 has been marked as a duplicate of this bug. ***
*** Bug 161028 has been marked as a duplicate of this bug. ***
I also had this occur on Windows 10; LibreOffice 24.2.3. With a custom Windows theme, dark mode enabled. It resolved itself after: 1. I enabled "Force skia software rendering" 2. Changed the icon set 3. Restarted LibreOffice 4. Selected Sakapura (SVG + dark) 5. Disabled "Force skia software rendering" 6. Restarted LibreOffice. I have now upgraded to Windows 11 so unfortunately am not in a position to test this further. It did not reoccur on Windows 11 as it was an upgrade, I did not replace my LibreOffice profile, and my custom Windows theme transferred over to Windows 11 unchanged (as far as I can tell).
Further to my last comment https://bugs.documentfoundation.org/show_bug.cgi?id=152534#c37 I recently upgraded to 24.8 and had to create a new LibreOffice user profile and the steps to correct this issue in my previous comment no longer work. I'm back to having unreadable activated icons in dark mode regardless of the settings. I have tried using my old profile with 24.8 and the icons now display like everyone else.
This appears to be an ongoing unresolved issue. I see this problem as far back as version 7.5.0.2, and I am using version 24.2.5.2(x86_64) and this annoying issue is still around with dark theme. I would suggest to the developers to just outline the selected toolbar selection with a border highlight only. This would resolved this issue with light and dark themes instead of using a Fill-Type highlighting. Or just reverse the toolbar selected text to a dark color when highlighting the selection with the light-blue color. Anyhow, Thanks for reading, and really hope this can be fixed. I have vision issues, now at age 56, and I can't see any thing in the selected toolbar selection with that light-blue fill and white text. Dark themes really help my viewing on software. And this is probably true for most vision impaired users. Thanks for any attempt to resolve this issue. Respectfully, Adam J.
I have to agree with Ash, Windows 11 will be the primary operating system from next year and by a significant margin the most widely used one. Having a broken dark mode is a real usability issue for many LibreOffice users. I understand this is caused by a Microsoft but that also impacts Notepad ++ and other applications but we should be looking for a work around if a non long term fix can not be reasonably implemented. I know this isn't a very useful comment to resolve the issue but it is a reminder that significant number of users have this issue and reminds us again that the largest number of our users arguably has the worst UI experience.
(Please keep version number as *earliest* version affected. Thanks!) With 7 duplicate, let's increase the priority.
(In reply to John Mills from comment #40) > I have to agree with Ash, Windows 11 will be the primary operating system > from next year and by a significant margin the most widely used one. Having > a broken dark mode is a real usability issue for many LibreOffice users. I > understand this is caused by a Microsoft but that also impacts Notepad ++ > and other applications but we should be looking for a work around if a non > long term fix can not be reasonably implemented. > > I know this isn't a very useful comment to resolve the issue but it is a > reminder that significant number of users have this issue and reminds us > again that the largest number of our users arguably has the worst UI > experience. I agree. I suggested the easiest way to resolve this issue is to re-think switching from a fill-type highlight to only highlighting the borders around the selection. I can see a color like a bright red, yellow, orange, or something working with light and dark themes. Just a thought.
How is the importance of this bug only "normal"?
(In reply to Adam James from comment #42) > I agree. I suggested the easiest way to resolve this issue is to re-think > switching from a fill-type highlight to only highlighting the borders around > the selection. I can see a color like a bright red, yellow, orange, or > something working with light and dark themes. Just a thought. Possibly. And IIRC, the MS Win11 WDM shows that when one of the "Contrast Themes" is in use. But this would require native Windows code for the backend, other VCL backends/osDE are not affected by this Windows 11 only issue caused by MS Dark mode API mis-configurations. Inverting the fg/bg is another potential tweak. But at that point might want to fully draw the button widgets with native Win32 Dark mode API. With added joy of having to shoehorn those buttons into the Glade .UI for the MUFFIN Notebookbar widgets. Just a lot more work and no real driver for the dev community to do so.
(In reply to Adam James from comment #42) > (In reply to John Mills from comment #40) > > I have to agree with Ash, Windows 11 will be the primary operating system > > from next year and by a significant margin the most widely used one. Having > > a broken dark mode is a real usability issue for many LibreOffice users. I > > understand this is caused by a Microsoft but that also impacts Notepad ++ > > and other applications but we should be looking for a work around if a non > > long term fix can not be reasonably implemented. > > > > I know this isn't a very useful comment to resolve the issue but it is a > > reminder that significant number of users have this issue and reminds us > > again that the largest number of our users arguably has the worst UI > > experience. > > > I agree. I suggested the easiest way to resolve this issue is to re-think However you do it weather that is a "correct" fix with code or the perfectly acceptable work around is neither here nor there.The issue needs to be fixed. Around 74 of desktop users worldwide are on Windows. https://gs.statcounter.com/os-market-share/desktop/worldwide Windows 10 goes out of support next year so the Windows 11 market will increase substantially. There is already an order of magnitude more Windows 11 users compared to desktop Linux. This is a substantial issue that needs to be resolved. If budget is required then The Document Foundation needs to tender a developer to do it both for UI consistency but more importantly accessibility as has been highlighted. It's ridiculous that Windows users are discriminated against in this way. > switching from a fill-type highlight to only highlighting the borders around > the selection. I can see a color like a bright red, yellow, orange, or > something working with light and dark themes. Just a thought.
(In reply to V Stuart Foote from comment #44) > (In reply to Adam James from comment #42) > > > I agree. I suggested the easiest way to resolve this issue is to re-think > > switching from a fill-type highlight to only highlighting the borders around > > the selection. I can see a color like a bright red, yellow, orange, or > > something working with light and dark themes. Just a thought. > > Possibly. And IIRC, the MS Win11 WDM shows that when one of the "Contrast > Themes" is in use. > > But this would require native Windows code for the backend, other VCL > backends/osDE are not affected by this Windows 11 only issue caused by MS > Dark mode API mis-configurations. > > Inverting the fg/bg is another potential tweak. But at that point might want > to fully draw the button widgets with native Win32 Dark mode API. With added > joy of having to shoehorn those buttons into the Glade .UI for the MUFFIN > Notebookbar widgets. > > Just a lot more work and no real driver for the dev community to do so. However you do it weather that is a "correct" fix with code or the perfectly acceptable work around is neither here nor there.The issue needs to be fixed. Around 74 of desktop users worldwide are on Windows. https://gs.statcounter.com/os-market-share/desktop/worldwide Windows 10 goes out of support next year so the Windows 11 market will increase substantially. There is already an order of magnitude more Windows 11 users compared to desktop Linux. This is a substantial issue that needs to be resolved. If budget is required then The Document Foundation needs to tender a developer to do it both for UI consistency but more importantly accessibility as has been highlighted. It's ridiculous that Windows users are discriminated against in this way.
So we have another user with the same issue on our Reddit page. https://www.reddit.com/r/libreoffice/comments/1ffrqwf/is_there_any_way_to_change_the_colour_of_toggled/ I should imagine we have thousands like this one.
(In reply to Caolán McNamara from comment #9) > Created attachment 185297 [details] > Windows 10 for reference > > Windows 10 looks ok AFAICS. Apparently my Windows box is not eligible for > upgrade to Windows 11 so someone else will have to investigate if this is > still a problem and what the solution might be. Notepad++, which also uses win32-darkmode and suffered from this same issue on Windows 11, was able come up with a proper fix that looks great back in May of 2024. The fix involved using a custom draw for the toolbar. Here is a link to the commit which fixed it: https://github.com/notepad-plus-plus/notepad-plus-plus/commit/fedaabf0f8d80ace2e63d73e5419b451ea6ea468 It fixed the bright blue highlighting on pressed state of the buttons and also when hovering the cursor over the buttons. This is C++ in Notepad++. I am not familiar at all with what programming language is used for LibreOffice on Windows so I'm not sure how feasible this would be. Thank you for all of the great work you have done thus far with dark mode on Windows.
Hello wildbydesign, Not sure if all or most of the complaints here are similar on the issue of this dark theme problem, however, the issue I have with my Libre Office dark mode is that, I don't need to hover or press, the color conflict is readily there. I can't read what to click on because the white text on light-blue background is a constant in the dark mode I am using. So, if this is a fix for only press down or hovering, it wouldn't help me here. but thanks for the input.
Created attachment 196776 [details] Image of Color Conflict Here is an attacked image of color conflict
(In reply to Adam James from comment #51) > Created attachment 196776 [details] > Image of Color Conflict > > Here is an attacked image of color conflict Thanks for posting the screenshot. That is definitely the same issue. You may not have pressed the buttons, but they are in a pressed state by default. It's absolutely terrible and needs to be fixed since this affects LibreOffice on default Windows 11 systems since it is the default Aero theme used for Dark Mode. I am hoping that this can be fixed in the same way in which Notepad++ fixed it because it didn't require too much code.
Yes, nice program for open source, and we do appreciate the years and effort in improving Libre Office. With that said, it is quite frustrating that this appears to be something on the back burner. This is something I could have solved quite fast. I have done programming over 35 years, and I can tell you, the method I suggested originally in this post I would think wouldn't hurt anything at all as far as the GUI design and operation. Anyhow, I'm ok with getting by with this, but I have to keep Word on the side for options from time to time.
(In reply to Adam James from comment #53) > Yes, nice program for open source, and we do appreciate the years and effort > in improving Libre Office. With that said, it is quite frustrating that > this appears to be something on the back burner. This is something I could > have solved quite fast. I have done programming over 35 years, [...] We welcome contributions! See https://wiki.documentfoundation.org/Development/GetInvolved
I have a Window Blinds theme set to dark mode in Windows 11 and am unable to see menu bar titles (File, Edit, etc...) and dialog/option boxes are unreadable due to this. Everything appears nicely when the theme is set to light mode. Changing LibreOffice options to system/dark does not alleviate the issue.
Yes, thanks for the invite in helping, however, I primarily wanted to be able to show the issue, which I see many are doing that. My primary focus of programming have always been PHP, some OLD BASIC, MySQL, and yes JavaScript. My current lifestyle, don't allow much, if any, active programming for this model. That is why I am only here to report and make a suggestion at this time. In best case scenario, I would love to get involved with this project at some later time, and who knows, maybe I can get a sample of the method I described submitted in some fashion. Hopefully, some active programmers on this project might consider what I suggested. Thanks for understanding my limited time of getting actively involved in this project at the time.
It appears that the issue also exists on the Windows 11 ARM version too. This is really going to become a "showstopper" on Windows 11 if you want to use dark mode. https://www.reddit.com/r/libreoffice/comments/1ftucl0/dark_mode_is_annoying_cannot_see_selected_icons/
(In reply to Adam James from comment #56) > My current lifestyle, don't allow much, if any, active > programming for this model. That is why I am only here to report and make a > suggestion at this time. > > In best case scenario, I would love to get involved with this project at > some later time, and who knows, maybe I can get a sample of the method I > described submitted in some fashion. Hopefully, some active programmers on > this project might consider what I suggested. Thanks for understanding my > limited time of getting actively involved in this project at the time. That's fair, thanks for your input. (Unfortunately, time of developers already active in this project is another limited resource, and not everyone has Windows 11 at hand either, which can be considered other reasons for this not being fixed yet.)
Understandable. That is also a good statement you made that may settle down some of the Window 11 users expecting any fast fix to this issue on that platform. Unlike my situation, if some of them have time for Windows Platform Libre programming, this may be a good time for them to get on board. Thanks for the reply. It makes sense.
*** Bug 163322 has been marked as a duplicate of this bug. ***
Just a reminder that this situation appears to be posted weekly if not more on support forums. There must be thousands of users frustrated by this issue. Other projects like Notepad ++ have resolved this problem. Is there progress a developer or someone at TDF can provide as this will only accelerate as Windows 10 becomes end of life in 2025? This is an awful first impression to have for Windows 11 users. https://www.reddit.com/r/libreoffice/comments/1g7dwhu/dark_mode_buttons_are_too_bright/
Created attachment 197174 [details] Screenshot with https://gerrit.libreoffice.org/c/core/+/175334 v1 in place Now that I have a Windows 11 VM, I've taken a look and submitted a potential workaround to manually draw background + frame for toolbar buttons when the dark theme is used on Windows 11: https://gerrit.libreoffice.org/c/core/+/175334 Attached is a screenshot with that change in place. Thoughts?
(In reply to Michael Weghorn from comment #62) > Created attachment 197174 [details] > Screenshot with https://gerrit.libreoffice.org/c/core/+/175334 v1 in place > > Now that I have a Windows 11 VM, I've taken a look and submitted a potential > workaround to manually draw background + frame for toolbar buttons when the > dark theme is used on Windows 11: > https://gerrit.libreoffice.org/c/core/+/175334 > > Attached is a screenshot with that change in place. > > Thoughts? Do we get usable response with getOSVersion().startsWith(u"Windows 11"), is the build version > 22000 a better test? Anyhow, commit and we can test... thanks!
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/620b293808f6111556c31674437917e70b106e9e tdf#152534 Win 11 Dark: Draw toolbar button bg + frame manually It will be available in 25.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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to V Stuart Foote from comment #63) > Do we get usable response with getOSVersion().startsWith(u"Windows 11"), is > the build version > 22000 a better test? `GetSalInstance()->getOSVersion()` returns a string starting with "Windows 11" based on the build version. Refactoring this a bit instead of relying on the string returned could indeed be a good idea, but can still be handled separately if this change is considered fine in general. > Anyhow, commit and we can test... thanks! Done now. Feedback welcome!
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/42c7e6848f61438f747c9509f17bef2dca29d937 tdf#152534 Win 11 Dark: Draw toolbar button bg + frame manually It will be available in 24.8.3. 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.
TB77 nightly build 20241223 of master against 25.2.0 Confirmed working well on Win11, in both Dark mode and no impact on Light mode. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f9263bbf3c06dbaec7577f2c7e2622f149073e7a CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to Michael Weghorn from comment #65) > `GetSalInstance()->getOSVersion()` returns a string starting with "Windows > 11" based on the build version. Refactoring this a bit instead of relying on > the string returned could indeed be a good idea, but can still be handled > separately if this change is considered fine in general. For the record: https://gerrit.libreoffice.org/c/core/+/176059