Changed background color #300
Conversation
Being able to distinguish a shut-off system from a locked system is precisely the reason why i3lock defaults to white instead of black. The color you’re suggesting in this pull request is too dark. We need something that definitely is clearly recognizeable as white, even on years-old laptop screens with backlights at the end of their lifecycle. I know that in web development, there are contrast ratios recommended for accessibility. Are there similar guidelines for what is acceptable in terms of solid colors? I’m curious. PS: If any color on your screen causes you discomfort, do you have the brightness of your screen too high? I usually find I need to reduce the brightness to 50% or less for my own viewing pleasure. |
Acknowledging this.
I asked around a bit and did a bit of research, it's the blue light that can generally cause migraines, photophobia, and affect sleeping patterns or the health of the average user negatively. If white's too harmful (LED vs. OLED) and black's too confusing, I guess that we should consider whether there's another middle ground. I'll conduct some further research and write back. |
FWIW, I’m not concerned with any color’s effect on physical screens. The lock screen is usually shown briefly when unlocking the computer. If you leave your computer locked for long periods of time, turn off the screen, which will be better for its health, no matter the color. |
I'm mostly talking about the effects of blue light and how that said effect can differ depending on the type of the monitor that the user is using, but that's besides the point. |
|
How about From a lighter perspective, I sort of dig |
|
I recently came across a study (https://www.sciencedirect.com/science/article/abs/pii/S2352721821000607) which concludes that blocking blue light might not make any difference, actually:
The colors you suggested are far from white. I thought we wanted to stick with white, and maybe tone it down to the minimum acceptable white? That said, maybe we should re-state what goal we’re trying to achieve. As mentioned previously, LED/OLED friendliness are not of concern, and the above study is counter-evidence to blue light being harmful. Aside from personal preference, which reason remains to change the color at all? |
|
Michael, blue light might not affect sleep outcomes but there is a plethora of bibliography regarding migraines and other effects: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4939697/ Since this is not our area and we have reports that the default white is uncomfortable for some people, why not change it? What are the arguments in favor of the white light? |
I’m not opposed to changing it, but I would like to have a good rationale for why we changed it, and what color we changed it to. Currently, we have 1 report of a user who found it uncomfortable, suspected issues with photo-sensitive users, longevity issues with display technology and the assertion that blue light is generally bad for a plethora of reasons, though at least part of that seems to lack good evidence. Maybe we end up with a rationale of “100% white can be jarring so we toned it down to 75% white”. I just want to avoid justifying changes like that with science, when there isn’t clear science to support our conclusions.
The current white color is the status quo. Changing it requires a justification, not keeping it :) |
Did some research but forgot to respond. I got word that people with astigmatism don't do well with white/bright text on fully black backgrounds because my website followed that specific color scheme. I looked at/skimmed over a couple of papers and documents/reviews over the past few weeks that surround the subject, I figured it'd be worthwhile to share them with some of my notes:
|
|
Hm, maybe the whole "I am not sure whether there's a lock screen or whether my computer is suspended" problem could be easily resolved by just rendering the circle from the get-go instead of waiting for keyboard input? |
Thanks for the suggestion, but there are multiple reasons why I’m not convinced displaying the unlock indicator (“circle”) immediately is a good idea:
Thanks also for sharing your research notes. AFAICT, all these papers research either prolongued exposure to certain lights, or performing tasks in certain light environments (e.g. reading text). None of this applies here; we’re rather talking about seeing a flash of light for a few seconds. I suppose it will be hard to find scientific evidence for the specific, narrow situation at hand. For now, I’m convinced that using a rationale along the lines of “100% white is perceived as uncomfortable by some users” is better than using any scientific studies. I think the only path forward here is to suggest a color value that is still white, but less than 100% intensity. Do you have a suggestion? |
Suggestions closer to gray
Suggestions closer to white
The GitHub preview is a bit small, not sure if I should share screenshots of me trying each individual combination instead or if I should link to an external website for the sake of simplicity. |
We can also try |
I do have a list of beige-like background colors too, I just wasn't sure whether to include it because it wasn't exactly light. But yeah, that color is not really as blinding and reading text seems to be easier. |
I just tried all suggestions and even this one (the closest to gray) seems fine, i.e. recognizeable as white. Can you update the commit and commit message accordingly please? |
Yup, thanks! |
|
Commit message says a3a3a3, but the commit itself still contains 1d1c1b? |
Sorry, did this in a rush and failed to add the file, my bad. |
|
Thanks! |
|
Great PR @panos, was going to suggest this myself but never had the courage to. |
Thanks! It's just a one-line change that was made based on my own experience as a user - and I think you can agree on that it was useful for the same reasons that I also had in the back of my head. I've been making various contributions to @haiku recently and I've been currently spending a lot of time communicating with people and issuing massive changes to its website in order to make other people comfortable, because they're all intimidated by the concept of working on an operating system when it's really just code. It really pains me to see many people with very good ideas end up being intimidated - we all turn out to be losers that way. .-. We're all in this together! :D (I may not be Dennis Ritchie himself, I'm just a kid that's having a lot of fun with all of this and I've only started contributing over the past year or so for the most part, but do feel more than free to contact me if you need anything revolving around that topic, @Raymo111) |
UX can make or break projects, and sometimes a one-line contribution is what we need. Have you seen i3lock-color? I've got a large superset of features and a lot to consider for improvements if you'd like to contribute. |
I'll give it a check later, thanks! It would be preferable that we don't discuss any further about this on here. ☮️ 🕊️ ✌🏻 |
Changed background color to #a3a3a3 (i3#300)
https://build.opensuse.org/request/show/1094956 by user avindra + dimstar_suse - update to 2.14.1: * unlock indicator: display only caps lock and num lock, not all modifiers like shift (which can leak information about your password to bystanders) - includes 2.14: * Change default background color to #a3a3a3 See i3/i3lock#300 for extensive discussion and rationale for this change. * Recommend using xss-lock to start i3lock in the README and i3lock.1 man page. xss-lock is the best way to ensure your screen truly is locked before your computer suspends * Display modifier key warning before unlocking, too, not just on failed attempts like before * Switch build system from autotools to meson
2022-06-21 i3lock 2.14.1 • unlock indicator: display only caps lock and num lock, not all modifiers like shift (which can leak information about your password to bystanders) 2022-05-28 i3lock 2.14 • Change default background color to #a3a3a3 See i3/i3lock#300 for extensive discussion and rationale for this change. • Recommend using xss-lock to start i3lock in the README and i3lock.1 man page. xss-lock is the best way to ensure your screen truly is locked before your computer suspends. • Display modifier key warning before unlocking, too, not just on failed attempts like before. • Switch build system from autotools to meson. 2020-10-27 i3lock 2.13 • Throw error when trying to start on Wayland • Use explicit_bzero() where available, not just on OpenBSD • avoid pixmap allocations in the redraw path • make --debug output go to stderr • unlock_indicator.c: fix build failure against gcc-10 • fix: call pam_end in cleanup in main, not in event loop • set _NET_WM_BYPASS_COMPOSITOR hint to avoid flickering 2019-07-21 i3lock 2.12 • remove stray \n from error messages • capitalize unlock indicator contents • set WM_CLASS property • reference modifier as “Super”, not “Win” • add --raw option to read image as raw bytes 2018-10-18 i3lock 2.11.1 • Fix dist tarball by including I3LOCK_VERSION 2018-10-10 i3lock 2.11 • Switch to autotools • Display an error when backspace is pressed without any input • Print an error when a non-PNG file is opened (i3lock only supports PNG files) (Thanks eplanet) • Don’t unnecessarily check the xcb_connect return value, it is known never to be NULL (Thanks SegFault42) • Fix memory leak when grabbing fails (Thanks karulont) • Respect Xft.dpi for determining the unlock indicator’s scale factor • Discard pending password verification attempts when a new password is entered (Thanks layus) 2017-11-25 i3lock 2.10 • Only use -lpam when not on OpenBSD (Thanks Kaashif) • locale: treat empty string same as unset (Thanks Ran) • Fix overwrite of getopt optind (Thanks jakob) • Immediately hide the unlock indicator after ESC / C-u (Thanks Orestis) • Measure wall-clock time instead of CPU time for “locking” indicator. • SetInputFocus to the i3lock window to force-close context menus • Use RandR for learning about attached monitors 2017-06-21 i3lock 2.9.1 • Fix version number mechanism (for --version) • Revert the fix for composited notifications, as it causes more issues than it solves: i3/i3lock#130 i3/i3lock#128 2017-05-26 i3lock 2.9 • i3lock.1: use signal names without SIG prefix • Removed obsolete inactivity timeout • Added version files for release tarball. • Set font face • Automatically unlock (without having to press <Enter>) one attempt which was entered while authenticating • Stop leaking the image_path dup • Displaying locking message when grabbing the pointer/keyboard • Display error message when locking failed • Add Enter on C-m • Change input slices to be exactly pi/3 in size instead of slightly more • Fix covering of composited notifications using the XComposite extension • Remove last traces of DPMS • Use bsd_auth(3) instead of PAM on OpenBSD • Restore intended behaviour and don't use mlock(2) on OpenBSD.
Hi, I don't usually try to enforce my own defaults in my open-source contributions, however, as I poked around with the code of
i3lockI came across thecolorvariable.When I initially tried out i3lock, I remember being woken up by the solid white lock screen color, and it's considerably hard on my own eyes when I'm even near my computer, let alone having to type the password itself. It was a bit tough, and I already even had a headache by the time that I logged in. I've also heard that super bright colors are frustrating to people with sensory issues (I haven't asked before making this change, so I can't be for sure as to whether my own change is helpful or speak for anyone else, but I'm bringing this up since that did happen to be one of the reasons as to why I made that one-line change. Please correct me if I'm wrong.).
I figured that a "pastel" dark color would be considerably better and much less annoying as a default than solid white. I thought of the AMOLED-friendly pitch black color, but, after using it as a default for quite some time, I had to stop, particularly because I had no idea whether my device was actually locked or shut off and I found that particularly frustrating when dealing with laptop lids. I'd be glad to discuss this a bit further and/or change the color.