Created attachment 114320 [details] Ruler Too Dark to Read with Dark Themes When dark themes are used the ruler is really hard to read. I suggest that the numbers, the lines, and the tab placement markers all be made white when dark themes are used. Not sure how possible this is - just a suggestion for UX. Image attached showing what I'm talking about. I'm currently running GnomishDark in Ubuntu 14.10 http://www.noobslab.com/2014/04/gnomishdark-gtk-theme-for-ubuntu-mint.html
Marking as new. Reproducible with LibO 4.1 under Kubuntu x64, but not reproducible with Libo 3.5, so it's a regression. I presume that this bug started with the "modifications" made to the ruler made for version 3.6. However I don't have version 3.6 nor 4.0 in any of my PCs
Created attachment 114360 [details] Ruler under LibO 3.5 with a dark theme applied
Likely a duplicate of bug 86617.
So it's not entirely a regression - although under 4.0 it's worse. Under 3.x it seems like at least the numbers are white but the stop markers are still dark so it's still quite hard to manage. Anyways - below if the bibisect for at least the numbering: 7cbcdae3f616c42e345dc92dfd17c957eecdccb9 is the first bad commit commit 7cbcdae3f616c42e345dc92dfd17c957eecdccb9 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun Dec 9 04:38:55 2012 +0000 source-hash-bb36072c92687a954a38aeca7fb9945f8e7cca13 commit bb36072c92687a954a38aeca7fb9945f8e7cca13 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Mon Apr 30 13:54:01 2012 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Mon Apr 30 13:54:01 2012 +0100 g_source_get_current_time has been deprecated since version 2.28 g_source_get_current_time has been deprecated since version 2.28 and should not be used in newly-written code. ... This function ignores source and is otherwise the same as g_get_current_time() not using g_source_get_time seeing as our baseline isn't there yet Change-Id: I9f389cbb8d23353c0a12eacb215d61256b28f643 :100644 100644 de536c71a2831ff44383cfc3d71fb50c892e5bc0 41c483e77a9ca1d1a9f17b23671e79f31eddbc1d M ccache.log :100644 100644 8e253cb7bef7938ce138ac5e9173dcc7b765746f 5a86afbe393645c87d7b8752740f045519c22f7e M commitmsg :100644 100644 a4708c68a86047fa937cf12d02235ab96a237915 b504bb9611fde69ccaa95f5bc54d0115b7367b11 M dev-install.log :100644 100644 760439c021441d95c64e40f76b80dbdbf3c99d11 f7887d14a9d386832bc75eee4091f7f444d604ad M make.log :040000 040000 fc84d55fcc5d105bf2f3b3a890d1918a45a5105e 08bf3836f0f2a7efebb3fcf10e8683a905e9b194 M opt :100644 000000 65c9a5f2ed3e153aaef732af2b65b93c0477843f 0000000000000000000000000000000000000000 D patch.log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect good 369369915d3582924b3d01c9b01167268ed38f3b # bad: [6fce03a944bf50e90cd31e2d559fe8705ccc993e] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 git bisect bad 6fce03a944bf50e90cd31e2d559fe8705ccc993e # bad: [8a39227e344637eb7154a10ac825d211e64d584c] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf git bisect bad 8a39227e344637eb7154a10ac825d211e64d584c # good: [e8bc60acad752e284db73fc4d8ad383ac055361c] source-hash-7e6e16ba6de2d3ef2b130d1ad5ffeabfdb37918e git bisect good e8bc60acad752e284db73fc4d8ad383ac055361c # good: [e1ec404400a4c6531a5d49d89631d1acc599071d] source-hash-5708f2bfa70db0479ddbf9b454329cd81e0f509d git bisect good e1ec404400a4c6531a5d49d89631d1acc599071d # good: [09b0c68ed3c0cb7a96ac98146a67e9540df994c8] source-hash-d50f02bec4a70bd26a518e4e76f4a876454ab937 git bisect good 09b0c68ed3c0cb7a96ac98146a67e9540df994c8 # bad: [7cbcdae3f616c42e345dc92dfd17c957eecdccb9] source-hash-bb36072c92687a954a38aeca7fb9945f8e7cca13 git bisect bad 7cbcdae3f616c42e345dc92dfd17c957eecdccb9 # good: [b119645386363b75d60215f91775cba82c1c6126] source-hash-3b328186706e6819acfea7b3a6dc8c9d3b6f9693 git bisect good b119645386363b75d60215f91775cba82c1c6126 # first bad commit: [7cbcdae3f616c42e345dc92dfd17c957eecdccb9] source-hash-bb36072c92687a954a38aeca7fb9945f8e7cca13
@Maxim - you interested in this one?
Joel M. has proposed a patch for this https://gerrit.libreoffice.org/#/c/20644/ Solution may need to be more ambitious. Either expose elements of the Ruler UI in Application Colors or possibly look at why the OS theme in use (dark or light) is not also populating the colorscheme elements that the Ruler pulls from. =-ref-= http://opengrok.libreoffice.org/xref/core/svtools/source/control/ruler.cxx http://opengrok.libreoffice.org/xref/core/vcl/source/app/settings.cxx
Be my guest - saying "do more" is not sufficient to hold back a patch. As it stands the color scheme is horrible for dark themes. This resolves that issue. If you want to do more though, I'm not going to stop you. Absent that, I hope that a patch isn't held back because there should be a larger change (done at some unknown time at some point in the future by a yet unknown developer).
(In reply to Joel Madero from comment #7) > Be my guest - saying "do more" is not sufficient to hold back a patch. As it > stands the color scheme is horrible for dark themes. This resolves that > issue. If you want to do more though, I'm not going to stop you. Absent > that, I hope that a patch isn't held back because there should be a larger > change (done at some unknown time at some point in the future by a yet > unknown developer). No, I'm only questioning doing something overly simplistic now, when correct handling should really not be that much more complicated. IIUC the issue only manifests when defaults for the colorscheme are not being overloaded when using an OS/DE with dark theme. Why is that? Is it simply not defined in the theme(s), or just not being mapped onto the element colors defined in app/settings.cxx? There are a few ways to tackle this, but a one off change in color assignment is probably not the best way. It muddles the default colors and those of and any lighter theme, and I am not so sure it fully corrects things for the Dark themes. I suspect we need to fix the methods for passing settings from OS/DE theme -> colorscheme mapping, especially for the dark themes. And as suggested, another way would be to expose these color controls to the GUI and to the Expert Config dialogs.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Version: 5.3.0.0.alpha0+ Build ID: d1c0a77ed1ba96b29e9b260b9ea1696634a9a094 CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group Still an issue. Moving to a bug since it's a regression - makes no sense to have it as an enhancement.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f50270ea5cb20c589edc2111e92412ffff4734ca Related: tdf#90214 gtk2 use a darkcolor based on the theme It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://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 "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9a1e401c082e66ca4d66218e61e2690f89340762&h=libreoffice-5-3 Related: tdf#90214 gtk2 use a darkcolor based on the theme It will be available in 5.3.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=308b0fcd2081e2a2665b572d62f7f07de85e2b45 Resolves: tdf#90214 set gtk[2|3] lightshadow halfway between darkshadow and bg It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://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 "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8114a779143a7f0042d7e15b476037315ed2b4c3&h=libreoffice-5-3 Resolves: tdf#90214 set gtk[2|3] lightshadow halfway between darkshadow and bg It will be available in 5.3.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 129119 [details] gtk3 screenshot dark adwaita theme
Created attachment 129120 [details] gtk2 screenshot dark adwaita theme
colors are now based on elements of the theme, i.e. disabled fg text color for darkshadow (which I had done already for gtk3) that's the text color used in the ruler, and lightshadow is now halfway between the bg color and darkshadow, that's the color used for the tick marks
I installed http://dev-builds.libreoffice.org/daily/libreoffice-5-3/Linux-rpm_deb-x86_64@70-TDF/2017-02-14_13.11.15/ on Kubuntu 14.04 GTK2 and GTK3 theme: Adwaita cat /etc/profile.d/libreoffice-fresh.sh export SAL_USE_VCLPLUGIN=kde using sudo dpkg -i *.deb and I don't have this fix: https://imgur.com/a/Dz90a The same for https://imgur.com/a/xGhUq from repository https://launchpad.net/~libreoffice Is is a distribution specific bug? What should I do?
Perhaps it was a wrong alarm. Sorry about that. I just checked 5.4 dev and it works. Thank you very much for this fix. But can you push it to 5.3.1 please? Please don't make user wait a few months for 5.4 official release.
*** Bug 86617 has been marked as a duplicate of this bug. ***