For many years I experience a puzzling problem with rclock. I use rclock on many different Slackware boxes which all feature the same slack version. rclock helps to keep ssh connections open. As my X and fvwm have a dark screen background I prefer rclock (or xlcock) to run with :
rclock -update 1 -bg black -fg blue
Now it happens that either at rclock start time or 'automagically' any time later the background and foreground color settings switch apparently for no reason so that rclock subsequently turns into a bright blue patch - which then annoyingly mimics my xbiff's mail arrival announcement. The only somewhat silly solution i have for now is to manually switch -fg and -bg each time when restarting a misbehaving rclock.
Any idea what causes this ?
Related
I've been building a website under Ubuntu 17.10 and use Firefox and Chromium for testing. The two browsers show quite different colors (not only for images but all colors) and I always thought that it is Chromium which for some reason wrongly over-saturates them, so up until now I always chose colors that looked right in Firefox.
But I'm starting to get more and more complaints about the website's background being too purple - which it shouldn't be in my opinion as only the blue component of it's color (#eeeeff) is "elevated", but it has reached a point that more people are seeing it as purple than blue, what makes me confused.
This is the aforementioned color displayed in Firefox (left) and Chromium (right).
And this is how I see a website:
The difference is quite large (notice how even the favicon is different) and I'm asking you to tell me which one is the browser I should trust when choosing the colours of my websites and whether I could do something to avoid it being displayed so differently in different browsers.
(There are some users that see the overly saturated colors in Firefox too. So now which is the right one, really?)
Another option is to open chrome://flags/ and select the option sRGB on the Force color profile item.
By using this setting instead of disabling the Use hardware acceleration when available, you don't lose some nice features like the 3D view on Google Maps.
Solution found here: https://www.reddit.com/r/Fedora/comments/74h5yh/blue_shows_as_purple_in_chrome/
Using GPick as a Color Picker and calling a Website with Color Hexcode like
http://www.color-hex.com/color-palette/54430
I see, that Firefox renders the RGB Colors exactly, meaning GPick identifies the same Hex Code from CSS.
Whereas Chromium renders some kind of differnt color.
You can call
chrome://flags/#force-color-profile
and set the Color Profile in Chromium to sRGB, so the rendered Color from Chromium is identified the same as the HexCode with GPick.
If you disable 'Use hardware acceleration when available' in Chromium Settings and relaunch, Chromium displays colors correctly. When turned on, Chromium colors are off. I consider this as a workaround until Chromium color management issue with hardware acceleration is resolved.
With the other two colours being equal, your colour is right in the middle of "blue territory".
If you convert it to HSL and look on the hue line, you can see it is right in the middle of the "blue" frequency range.
Consequently, any hint of green or red is incorrect.
I am working on terminal Vim colorscheme (for 256-color terminal) and I need a few dark colours that I could use as backgrounds. I'm not satisfied with ones available in standard palette - for example, color 22 (#005f00), the darkest shade of green, is still too bright.
I've read that terminal Vim does not allow specifying colors as RGB, so - to get arbitrary colors - I would have to tweak terminal emulator's color palette. Is there a way to tweak full 256-color palette in gnome-terminal / terminator? Preferences window only allows editing basic 16.
BTW, Chrome's hterm allows this via 'color-palette-overrides' preference (but has its own drawbacks).
Gnome-terminal doesn't offer a UI to alter the colors (apart from the first 16), but you can use escape sequences, e.g.:
echo -ne '\e]4;22;#004f00\a'
As you've mentioned, sometimes these colors get reset to their default values. This was a bug in the underlying VTE library, and got fixed in version 0.36.
As far as I know, you won't find a single terminal emulator that gives you that kind of control over the whole standardized xterm palette.
So, if you ever intend to share that colorscheme you are stuck with the default palette.
On the other hand, if that colorscheme is only meant for your usage or if you are OK with forcing a hard dependency on your users, you can use japh's colorcoke to generate an alternate palette more suited to your needs. See the repo's wiki for examples)
My setup includes vim, iTerm2, tmux, and the solarized dark color scheme. I have the dark solarized color palette loaded into iTerm2 (modifies the ansi colors) and do not use the degraded solarized color scheme (i.e., let g:solarized_termcolors=256) as talked about in the readme as an alternative to using the color palette. Everything looks great.
But, I often remote pair with co-workers. Folks ssh into my machine from other instances of iTerm2 and sometimes Terminal.app and create a new tmux session with my tmux session as their base/parent session. In the case of iTerm2, their setup does not include loading the solarized color palette (one uses another palette entirely) and setting the let g:solarized_termcolors=256 to use the degraded solarized color scheme. If that's what they want, great, but when they connect to me via ssh/tmux the colors are lost and often times distorted to the point of being illegible.
Is there any combination of settings, besides having everyone use the same settings, to remedy this? Right now the recommendation is for me to use the degraded color scheme and not load the solarized color palette so that the ansi colors are not modified. This does work, but leaves me w/ the degraded solarized color scheme. And as I prefer the non-degraded solarized color scheme, I'd prefer not to take this approach.
When used in a terminal, the solarized colorscheme for Vim defaults to 16 colors and depends on the palette of the terminal emulator because it uses "Red", "Yellow"… as values for ctermfg and friends.
If you want the same colors everywhere you obviously need to have the same palette everywhere because your "Red" may not be someone else's "Red".
I don't know what the author smoked when he wrote it but let g:solarized_termcolors=256 is not "degraded" at all compared to the default. The default uses only a palette of 16 colors (dependant on the terminal's palette, as we have already seen) while this option makes it use a terminal-independant 256 colors palette. Because the colorscheme is not dependant on the terminal emulator's palette anymore, the colors are actually "guaranteed" to look "good" and "the same" on your terminal emulator and on someone else's terminal emulator.
The catch is that your terminal emulator and their terminal emulators must support 256 colors. All of todays terminals do, but the default is often set to 16 colors. It's generally easy to turn 256 colors support "on", though.
But this option is Vim-only. The colors of your prompt or of the output of some commands or of tmux's TUI may still feel "off" to your co-workers.
The ability to customize the hell out of your setup is of course an important aspect of the Vim experience. But customization comes at a price. You get used to many little things and it could happen that, confronted to a vastly different setup, well… you just get lost. Or, as happens to you, your setup is customized to the point of being unusable by your co-workers.
Pair programming can only work if you and your pair are able to reach compromise on a setup. Obviously, this setup may not be exactly yours or his but you must find a middle ground on which everyone agrees for pairing to work. Because you and your pair may use different versions of tmux/vim, different shells or different terminal emulators, the safest bet is to use the most basic setup possible. Unfortunately for you, solarized is too fragile and far from being "basic" enough.
I am using Redhat Linux and the problem I am facing is that the "blue" colour of the directories is hardly visible on the black background. I found some posts on the web which asks to change some settings in the file /etc/profile.d/colorls.sh and /etc/profile.d/colorls.csh. However, this will change the colour settings for everyone who logs into the system. Could someone please let me know how I can change the colour settings that will affect only me?
To specify the colors of the output of ls, you need to set LS_COLORS. In your .zshrc, try adding:
LS_COLORS="$LS_COLORS:di=00;33"
34 is blue, 33 is ... yellowish. Change that number and find what you like.
Use dircolors to get a feel for what LS_COLORS should look like and add -p to see a color list.
Joachim's answer is good for fixing the specific issue of directories, but if any other utilities output using the "blue" color, you will find them just as unreadable.
Different terminal emulators have different settings for changing the colors; my terminal emulator of choice reads X resources to determine what colors to use:
URxvt.color0: #000000
URxvt.color1: #A80000
URxvt.color2: #00A800
URxvt.color3: #A8A800
URxvt.color4: #0000A8
URxvt.color5: #A800A8
URxvt.color6: #00A8A8
URxvt.color7: #A8A8A8
URxvt.color8: #000054
URxvt.color9: #FF0054
URxvt.color10: #00FF54
URxvt.color11: #FFFF54
URxvt.color12: #0000FF
URxvt.color13: #FF00FF
URxvt.color14: #00FFFF
URxvt.color15: #FFFFFF
color4 is the blue in question; I have mine set like this:
URxvt.background: #000000
URxvt.foreground: gray75
URxvt.color3: DarkGoldenrod
URxvt.color4: RoyalBlue
URxvt.color11: LightGoldenrod
URxvt.color12: LightSteelBlue
URxvt.color7: gray75
URxvt.colorBD: #ffffff
URxvt.colorUL: LightSlateGrey
URxvt.colorIT: SteelBlue
URxvt.cursorColor: grey90
URxvt.highlightColor: grey25
This gives a black background, not-too-bright foreground, and most other colors are reasonable enough. (I too found the default blue unreadable.) I put these into my ~/.Xresources file, and they take effect after log in or after merging this file with the X resources database: xrdb -merge ~/.Xresources.
Of course, different terminals are configured differently. Check your terminal's manpage for more details on changing the colors of the usual colors.
You can see what is done in the global file, and then add it to your private ~/.profile (or similar file.)
samolod solution is good.
In case of KDE konsole you go to
Settings -> Edit current profile -> Appearance -> Edit -> Color 5.
Then use graphical color chooser to make it brighter (I picked #5871FF).
In each web app I develop, I like to add three types of messages:
Green/blue for success messages
Yellow for warnings
Red for errors
And perhaps, a neutral one for information, which is gray or blue if the success one is green.
The success one is used for when an item is created or updated, the yellow one is when there's something wrong, but not we-are-going-to-die wrong and the red one is when something is blocked or we are going to die.
However, there's one thing I can't figure out, when I delete an object, what kind of notification should I use? I think the success one is not because it is not expected, altough the deletion was successful, the user tends not to read the message, just to see the color.
The red one might be, but it can be misunderstood (I tried to delete it but there was an error), the warning and the information one might be good choices, but I'm not really sure.
Also, when you ask for confirmation about deleting something, the 'cancel' button should be green or red?
I'm just curious how you guys handle this. Thanks.
In general, I rely on the OS to provide appropriate colors.
The problem is with vision-impaired users. I can't predict whether or not they can read text set against any background I might choose. I assume that they've configured their browser and OS to display the colors that they can read the best.
Mike brings up a good point. Using colors assumes the user can see colors. Perhaps adding an icon (with contrasting foreground and background colors) to your messages may help with the ambiguousness.
For example:
Exclamation: Exclamation point in a triangle with a yellow background.
Asterisk: Lowercase letter i in a talk bubble.
Stop: White X in a circle with a red background.
Error: White X in a circle with a red background.
Warning: Exclamation point in a triangle with a yellow background.
Information: Lowercase letter i in a comic bubble.
Question: Blue question mark in a talk bubble.
I usually do it the following way:
If the user's intention was to delete something, and he did, I show it in green. If they don't read it because its green, they will assume that whatever they wanted to do has been done correctly.
At the "are you sure?" stage, the user may have gotten there by accident, so if you give a color, he may get confused or scared. I keep the "delete/cancel" buttons in a neutral color.