Description: Look at the picture in this Tweet for the best demonstration: https://twitter.com/libreoffice/status/1062283809037733889 This applies to any "important" symbol or character that is solid black, usually a styled capital "A" or the paragraph symbol, but could include others. Solution: Make the black in the styling buttons the same color as the gray in the R L C J paragraph styling buttons. This gray already works well, no testing needed before the first fix. Dilemma: Creating separate icons for a light and dark theme invites more compatibility issues with backend theming, as well as not necessarily being compatible with individual themes. A unified, single set of icons would be best. In that, find the ideal color, which is already working with the paragraph styling buttonw. Steps to Reproduce: 1. Use Ubuntu or a GTK-themable environment. 2. Set the theme to Adapta-Nokto, Arc-Dark, Vertex-Dark, Vimix-dark, Yosemite-Dark, or any other dark theme. 3. Look at the Bold, Underline, Italics, Superscript, Subscript, Clear-formatting Actual Results: Can't see buttons as clearly. Expected Results: See buttons more clearly. Reproducible: Always User Profile Reset: No Additional Info: The paragraph buttons have some highlight and shadows in them. This is often used for a semi-3D effect, but could be a part of the paragraph button's high visibility. I strongly suggest using a similar method of highlights and shadows on these black symbols. Linux love all around!
*** Bug 121379 has been marked as a duplicate of this bug. ***
Thank you for reporting the bug. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Created attachment 150982 [details] dark theme and elementary in gtk3 the issue is not only that the color of bold, italic, ... icons is to dark, that can be fixed with an additional dark elementary icon theme), the issue is also that the "grayed out" commands like cut, copy, ... didn't work as well. If LibO want to have dark theme support, than I suggest that 1. the "grayed out" commands will work nicely 2. an automatic dark theme will be used from the selected icon theme It is not useful that the user can select between elementary, elementary_dark and elementary_svg. as the svg theme support is not in an proper shape, I recommend to make an elementary icon theme (.png) and if you select an dark gtk3 theme, LibO will use elementary_dark as elementary_dark (or any other dark theme) fallback to elementary, the icon designer ONLY have to add the black elementary icons to elementary_dark. that will give the user the second best solution (1st solution will be svg support), but there you also need an color scheme support).
Don't like the idea of duplicate styles for every flavor. Dark themes just don't fit Elementary and we have plenty (okay: some) alternatives like Breeze_Dark (which IMHO shouldn't be just an inverted icon theme but distinct and respectively named). What we also can do is to adjust colors programatically (works only with SVG). But still I think it's too much trouble. What if I complain about badly readable icons in my pink system theme? Ship also Breeze, Sifr, Elementary in green variations? Admittedly, that's goes a bit too far as dark themes are popular.
There is already an color scheme support bug and when svg icons can be used, color scheme support will be available. So you can use than also pink fluffy theme.
Dear JesseSteele, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear JesseSteele, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp