-
Notifications
You must be signed in to change notification settings - Fork 367
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
DF description/missing color is unreadable on dark themes #3400
Comments
Thank you for the comment. Do you have a recommendation then? CC @ronisbr |
Thank for the quick reply! I think one of the colours should be chosen, as neither This leaves Julia seems to mostly use This webpage might be helpful. Here are some theme examples: |
Hi! Fixing this issue would be extremely simple since we just need to change the color here: Personally, I have no idea what would be the best option. |
The best option, I guess, would be to select |
In summary: we are OK to change this given we know what color to pick. The restriction is that:
|
Hum, there is no universal way to check if the theme is dark or light AFAIK :( |
I agree 100% with @bkamins 's proposal here. |
I searched for a bit, but it doesn’t seem possible to tick both boxes. Maybe then hardcoding a medium gray, which is suitable for both theme variants? |
Do you mean, setting a RGB color? |
I think it would make sense to hardcode RGB medium gray (I guess it is possible - right?) |
In the shell it sure is, I just don’t know how Julia interfaces with that. Shells use strange color codes like |
The problem is for terminals that do not support 24-bit colors. I need to test to check what will happen. |
This code says the terminal must change the foreground color to red. In PrettyTables, we use Crayons.jl that is a conversor between a color and those escape sequences. Maybe we can assume everyone will be using at least a terminal that supports 256 colors. In this case, we have access to a wider range of colors. IMHO, assume 24-bit color is too much restrictive. In the case of 256 colors, there are those options: ![]() (from https://www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html) Thus, we can select a color between 232 and 255. |
You can also substitute |
But AFAIK it is converted to a 24-bit color code, which should not work in terminals that do not support it. |
While we’re at this: Is it possible to specify this color as an environment variable or by a function call? I guess that would be nice for circumventing corner cases due to hardcoded values, for example in the rare case anyone has a grey background. |
Yes, it should be fine to check if a ENV variable is defined and use this value instead. Maybe it will add an overhead, but should not be noticeable. What do you think @bkamins ? Any suggestions about the variable name? |
In the past we have had a policy not to introduce behavior depending on global state. @nalimilan - in this case do you think it would be acceptable? |
Isn't this the same problem as JuliaLang/julia#38730 caused by the fact the solarized theme uses same colours for background and foreground? |
Yup, seems so. Thanks for the tip, now I see that my stack traces contain more information than what is visible. 😅️ |
I would find it kind of weird to have a mechanism to set the color used when printing a particular object ( Anyway, regarding this particular issue, requiring users to set an environment variable seems suboptimal. Most of them won't even know they can do that. Is there a way to check whether |
Unfortunately no. There is no universal way to check what is the color the terminal will use given a ANSI escape sequence. |
My proposal was to use medium gray by default and only if that collides with themes (which then are neither light nor dark but rather something in the middle, which I assue to be pretty rare) users are required to manually chose a suitable color for de-highlighting. The problem is, that terminals just define highlighting-colors but no de-highlighting-colors. |
Notice that this is only possible if we assume a terminal capable of outputting 256 colors since the default 8 colors only contains bright black as gray. IMHO, I think the number of people using terminals that cannot output 256 colors should be minimal. Thus, it should be fine to select one of those colors: ![]() Assuming 24-bit and selecting the RGB values is way more restrictive. @fbruetting can you please test in your terminal what would be a good gray selection for those themes? To do so, open a terminal with your theme paste: |
Side note: the same issue applies to the column type subheader. |
Not having a good contrast is much less of a problem than not seeing those values at all, so I’d still prefer hardcoding medium gray. Here’s a comparison of common themes for the colors 240-247 (all of these are shipped with Tilix): Solarized Light / Linux / TangoSolarized Dark / Material / Monokai Dark / Orchis / Yaru / Base16 Twilight dark |
What if we took a relatively dark grey like 238, which is not super readable in Solarized Dark but is at least discernible and better than the current situation on that theme? Anyway it's not hard to find out that these entries correspond to missing values, what matters is that you notice the cell isn't completely empty. |
Relevant Solarized bug: altercation/solarized#220 When I read this, there are MASSIVE complications and Solarized is to blame because of intentionally violating the specification. It might be better to let everything be as it is and let Solarized be broken, because when you’re fixing the colors for Solarized, all other themes suffer, because DF then hardcodes values in an environment where all other colors are variable. Best solution would be to indroduce a config setting, which lets Solarized users alter that color if there’s need, then every other theme would work perfectly and there won’t be compromises at all – just a manual fix for an intentional spec violation. Seems the correct approach to me. Solarized just needs to fix the palette, or needs a fork, obviously. |
I totally agree. I had problems with solarized themes in the past for a similar reason. Thus, the option is to define a ENV variable that will change the colors in subheaders and in those highlighters. |
Actually, it would be best if Julia would implement that grey-color ENV/setting (if that’s not already possible) and DF to then refer to that Julia-grey-color-setting. Then we’d have a Julia-global solution. @nalimilan ? 😄 P.S.: Even better would be if Julia could be able to modify that color and pass it on to all packages, then no package has to implement such a reference, but I don’t know if this would even be possible. Should I open up an issue in Julia for that? |
I agree that Solarized seems broken. Given that it also affects Julia (and even more seriously than DataFrames), I'd prefer to find a more general solution there, e.g. which would allow overriding the colors that correspond to each named color. This should ideally be used by Crayons and we wouldn't have anything to do here. |
I think this is not the correct approach. Crayons.jl uses the escape sequences given the ANSI definitions. It should not modify the colors. The correct way to replace a color is to set the desired one in your terminal, by changing its theme. Of course, each application (DataFrames in this case) can provide a mechanism to tune the colors it uses if necessary. Since there is no definition of a "theme" in DataFrames because we only use few colors by default, I think an ENV to address this specific problem would not be bad. |
It’s not always possible to modify the color palette. In GNOME Builder you for example can just select a theme but not modify it. I think we should shrink |
No, it will not be global. There are packages, like Term.jl, (and Julia itself) that just output the escape sequences without using Crayons.jl at all. It will not have the intended behavior of a global fix. IMHO, if a theme is setting something that violates the ANSI specification (making a color equal to background when it just should not happen), the theme must be fixed. Even inside PrettyTables.jl this will not be global. We have a text cell type called Allowing Crayons.jl (or anything) to manually change the color can lead to a lot of problems. Example: Package A uses |
Btw, I was reading about the fixes in all the backlinks to that issue in solarized theme. Almost all involve changing the theme color in the application. |
Hm, I understood nalimilan so as that the core color definition happens in Crayons and everything else refers to that. You’re correct that the theme needs a fix, but reality is that this wasn’t fixed in 10 years and yet it’s usage went through the roof – so you can be sure that that won’t happen. There needs a fork to be established, which is a process of at least a decade, so we can’t do anything here, therefore the ugly ENV fix idea. For fixing the applications it’s the question of which color to put there. Guess that’s arbitrary then. But I also see your point in the logic chain “application ships a broken theme” ⇒ application needs to fix it. |
Yes, this is precisely my point! However, I also agree that solarized is indeed very popular. Hence, IMHO, the optimal approach (given the circumstances) would be an ENV in DataFrames that at the end is selecting the color for specific types of cells. |
But that is |
In this case, I do not agree because the only global fix will be fixing the theme, as many others are doing. If we change the color definition in Crayons.jl, we fix this issue in DataFrames.jl, but the stack traces will continue to be unreadable. IMHO, changing the color inside the application is like type-piracy. The terminal you are using is responsible to render the |
Looking at JuliaLang/julia#38730 I realize that Julia already has a workaround via e.g. I'd argue that the best place to do this would be even more upstream, i.e. in Crayons and similar packages, to ensure consistency. But anyway since this has to be set manually it won't affect users that don't want it so it won't make things worse than the current situation. |
In the picture below you see a DataFrame in combination with following themes:
Solarized Dark is one of the most popular dark themes, because of its very good readability as its contrast being neither too low nor too high. Without modifications,
missing
s and column types are not readable at all.I found out that this is due to DataFrames using the “alternate black” color – which on dark themes usually is equal to the background color, or at least very near. So it’s not a problem at all on light themes, but all dark themes have problems with this (not just Solarized). See the following examples with the themes:
I haven’t encountered these issues anywhere else, neither in my IDE (GNOME Builder), nor in general Julia, so I guess the problem’s root is this package’s color selection. I guess it’s necessary to chose another color here, as “black” just works well one bright themes.
The text was updated successfully, but these errors were encountered: