Bug 90214 - Ruler Should be White When Gtk2/Gtk3 Dark Themes Used
Summary: Ruler Should be White When Gtk2/Gtk3 Dark Themes Used
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: medium minor
Assignee: Caolán McNamara
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.3.0.1
Keywords: bibisected, regression
Depends on:
Blocks: GTK3 UI-Theming Rulers
  Show dependency treegraph
 
Reported: 2015-03-25 02:49 UTC by Joel Madero
Modified: 2017-06-19 03:43 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Ruler Too Dark to Read with Dark Themes (162.10 KB, image/png)
2015-03-25 02:49 UTC, Joel Madero
Details
Ruler under LibO 3.5 with a dark theme applied (47.09 KB, image/png)
2015-03-26 02:23 UTC, Francisco
Details
gtk3 screenshot dark adwaita theme (82.44 KB, image/png)
2016-11-29 13:27 UTC, Caolán McNamara
Details
gtk2 screenshot dark adwaita theme (81.12 KB, image/png)
2016-11-29 13:28 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joel Madero 2015-03-25 02:49:59 UTC
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
Comment 1 Francisco 2015-03-26 02:20:48 UTC
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
Comment 2 Francisco 2015-03-26 02:23:07 UTC
Created attachment 114360 [details]
Ruler under LibO 3.5 with a dark theme applied
Comment 3 Yousuf Philips (jay) 2015-04-27 05:19:55 UTC
Likely a duplicate of bug 86617.
Comment 4 Joel Madero 2015-04-30 06:09:04 UTC
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
Comment 5 Joel Madero 2015-11-16 05:02:28 UTC
@Maxim - you interested in this one?
Comment 6 V Stuart Foote 2015-12-11 17:19:05 UTC
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
Comment 7 Joel Madero 2015-12-11 18:34:54 UTC
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).
Comment 8 V Stuart Foote 2015-12-11 21:09:04 UTC
(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.
Comment 9 Robinson Tryon (qubit) 2015-12-13 10:30:14 UTC Comment hidden (obsolete)
Comment 10 Joel Madero 2016-07-12 17:52:53 UTC
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.
Comment 11 Commit Notification 2016-11-29 12:58:26 UTC
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.
Comment 12 Commit Notification 2016-11-29 13:00:28 UTC
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.
Comment 13 Commit Notification 2016-11-29 13:25:45 UTC
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.
Comment 14 Commit Notification 2016-11-29 13:26:06 UTC
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.
Comment 15 Caolán McNamara 2016-11-29 13:27:38 UTC
Created attachment 129119 [details]
gtk3 screenshot dark adwaita theme
Comment 16 Caolán McNamara 2016-11-29 13:28:20 UTC
Created attachment 129120 [details]
gtk2 screenshot dark adwaita theme
Comment 17 Caolán McNamara 2016-11-29 13:31:48 UTC
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
Comment 18 gnomek 2017-02-15 12:04:44 UTC
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?
Comment 19 gnomek 2017-02-16 10:47:38 UTC
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.