-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JENKINS-8958 Code coverage color scheme not suited for color blind users #95
base: master
Are you sure you want to change the base?
Conversation
@@ -0,0 +1,123 @@ | |||
table.source { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My concern with duplicating the entire css file is that anyone wanting to change the layout would have to change in two places (and might miss this one). Looking at the layout control https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/lib/layout/layout.jelly#L46-L49 I see the css
parameter is deprecated.
This suggests a slightly different approach, which would be to move the css path into a <script>
tag inside of an <l:style>
control. Then we could provide a color-blind css file that has just the overrides (presumably the colors). For regular mode, just import the base stylesheet, and for color-blind mode import the base stylesheet, then import the color-blind stylesheet. This has the advantage that we could easily provide more than one color-blind mode in the future should we want to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, You are right. Thanks for your advice :)
@@ -47,6 +41,9 @@ | |||
@ExportedBean(defaultVisibility = 2) | |||
public class CoverageResult implements Serializable, Chartable { | |||
|
|||
private static final String DEFAULT_CSS_FILE = "style.css"; | |||
private static final String COLOR_BLIND_CSS_FILE = "style-color-blind.css"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think these two constants are being used anymore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just minor comments
* | ||
* @return whether enable color blind mode in global config | ||
*/ | ||
public boolean isEnableColorBlindMode() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice2 have: @since TODO
for new APIs
import hudson.plugins.cobertura.CoverageChart; | ||
import hudson.plugins.cobertura.Ratio; | ||
import hudson.model.*; | ||
import hudson.plugins.cobertura.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is generally preferable to avoid it in the production code, because there is a risk of ambiguity if one of the packages introduces a competing class.
/** | ||
* load global config from disk | ||
*/ | ||
public DescriptorImpl(Class<? extends Publisher> clazz) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it actually used anywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment of Descriptor
said Descriptor can persist data just by storing them in fields. However, it is the responsibility of the derived type to properly invoke save() and load().
So I call save()
in configure()
to persist global configuration. And the comment of load()
said The constructor of the derived class must call this method. (If we do that in the base class, the derived class won't get a chance to set default values.)
. So I follow the comment to implemented its two constructors and call load method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally it would make sense to have a Jenkins-wide colorblind mode. There
were some discussions about that in PRs, but we do not have API for that so
far. OTOH it could be an intetesting project idea, e.g. for GSoC next year
…On Mar 15, 2018 15:38, "Jeff Pearce" ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/main/java/hudson/plugins/cobertura/CoberturaPublisher.java
<#95 (comment)>
:
> @@ -889,6 +891,23 @@ public ParseReportCallable(String reportFilePath) {
CoverageMetric.LINE,
CoverageMetric.CONDITIONAL,};
+ /**
+ * load global config from disk
+ */
+ public DescriptorImpl(Class<? extends Publisher> clazz) {
It provides a config setting on the plugin page:
[image: screenshot 2018-03-15 07 36 24]
<https://user-images.githubusercontent.com/1479145/37470052-e2d9b21a-2823-11e8-9249-77325ac490e6.png>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#95 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AC3IoP_UW97p-sXksmKCVwgI00-HNVoXks5tenz-gaJpZM4SijvE>
.
|
That was my initial thought as well. I could see doing the work in Cobertura now, and converting it to use the global setting later. Do you think that's worthwhile, or should we close this one? |
I guess the global config might have specific colors though, so it's not clear it would be a 1:1 translation to this code |
Maybe a User Property instead of global? or both |
@steven-foster can you elaborate? I'm not sure what the difference is between User and global property |
@jeffpearce Should I extended color-blind mode more than just in coverage bar but also in trend image and so on? |
That makes sense to me |
OK, the trend image and source line mark are also unsuitable for color vision impaired person. I think I should change them all. |
👍 Thanks again for the hard work on this plugin |
@jeffpearce I add more diversity to the origin chart lines. So not just for the color-blind people but for normal people can differentiate it easier. Now what do you think of it? |
@jeffpearce a UserProperty would allow each user to configure it for themselves, rather than a global configuration which would change it for everybody using the Jenkins instance. It's just a suggestion, there might be a reason not to do it this way :) |
@steven-foster - that would be good. I could see this as a next step, and UserProperty down the road, so it could be configured per-user |
@cizezsy - I'm sorry, this fell off my radar. Can you remind me where we're at? Is this ready for another round of review? |
@jeffpearce My fault, I do not say it clearly. I have changed the line shape of trend image so that it will be more friendly to the color-blind user. But, the original image is not clear also for normal users. So I think we should not add this change just for colorblind mode but for all users. Maybe I should start another pull request like "improve trend image" to do this thing? |
@cizezsy - do you think this PR is still relevant? |
@jeffpearce I think this PR can be closed... |
Add global config which can enable colorblind mode.
I use a Chrome extension which simulates the website as a color vision impaired person would see. And the following is the results.
Normal see it:
Red-blind see it:
Green-blind see it:
Blue-blind see it: