Bug 369676 - White lockscreen text's readability depends on background
Summary: White lockscreen text's readability depends on background
Status: RESOLVED FIXED
Alias: None
Product: Breeze
Classification: Plasma
Component: general (show other bugs)
Version: 5.8.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Development Mailing List
URL:
Keywords: usability
: 367764 369999 392964 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-10-03 13:19 UTC by markuss
Modified: 2018-04-29 13:05 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.13


Attachments
What you see right after the screen locks (83.02 KB, image/jpeg)
2018-03-16 16:38 UTC, Nate Graham
Details
What you usee after any user input (80.96 KB, image/jpeg)
2018-03-16 16:41 UTC, Nate Graham
Details
attachment-6928-0.html (3.23 KB, text/html)
2018-04-23 07:05 UTC, Pascal d'Hermilly
Details

Note You need to log in before you can comment on or make changes to this bug.
Description markuss 2016-10-03 13:19:53 UTC
Plasma 5.8's new lockscreen design features white text that, depending on the background (e.g. an image), is barely readable.

Reproducible: Always

Steps to Reproduce:
1. Pick a beautiful photo of a misty or snowy landscape for the lockscreen
2. Lock the screen


Actual Results:  
Text not readable

Expected Results:  
Some sort of text effect would be nice. A drop shadow, a faint outline, or something like that.
Comment 1 Christoph Feck 2016-10-07 02:33:07 UTC
*** Bug 369999 has been marked as a duplicate of this bug. ***
Comment 2 Pascal d'Hermilly 2016-10-23 21:01:19 UTC
Same on Neon 5.8.2.
It's written in QML right?
Isn't it just adding this? : 
    style: Text.Outline;
    styleColor: "black"
Comment 3 Juri Vitali 2017-03-04 22:39:10 UTC
Same here, I noticed that to switch to a black text mode is sufficient to change line 32 of /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml from
colorGroup: PlasmaCore.Theme.ComplementaryColorGroup
to
colorGroup: PlasmaCore.Theme.ViewColorGroup
or remove the line altogether.

Now, the only think I think is needed is a logic to choose between white and black (or other color) text depending on the image supplied.

This is especially important when the image comes from an image provider (as National Geographic, APOD, etc.), as the picture changes daily and it is not reasonable to manually edit the file each time.
Comment 4 Rog131 2017-03-05 15:30:42 UTC
The ui can be placed on the top of sliding cover.

The ui will be on sight only when it is needed. An example: https://forum.kde.org/viewtopic.php?f=289&t=131783&p=372930#p372930

YouTube: https://youtu.be/7gsJkSYRIw8
Comment 5 Rog131 2017-05-03 14:33:11 UTC
Dublicate / same kind of as Bug 374300 - Option to change the font color on the lock screen - https://bugs.kde.org/show_bug.cgi?id=374300
Comment 6 FabiB 2017-06-09 09:42:48 UTC
Maybe it would be better to use the Plasma themes background as background for the Textareas/mediaplayer.

Because we dont know what picture the user is taking and there are some cases where no white and no black text is good readable. So a background image would be better.
Comment 7 Navid Zamani 2018-02-04 22:17:11 UTC
Since this is still a problem …

(In reply to Juri Vitali from comment #3)
> change line 32 of
> /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/
> LockScreenUi.qml from
> colorGroup: PlasmaCore.Theme.ComplementaryColorGroup
> to
> colorGroup: PlasmaCore.Theme.ViewColorGroup
> or remove the line altogether.

I just tried that, and it doesn’t work.

I switched my theme to Oxygen, changed the file you mentioned, saved it, switched the theme back to Breeze. Nothing changed.

I’m for giving the text a subtle outer glow of the opposite brightness than the text. So as if the white text had a lamp on its back side, that emits light, except the “light” is black. That way, it looks "white on white" but still perfectly readable, and very elegant.
The reason it looks so good, is because in the real world, a white raised object put on top of a white table will block some light from reaching the concave corners, and our eyes detect the difference in depth and add even more contrast to the edges. That is the intended look.
Comment 8 Navid Zamani 2018-02-04 22:18:34 UTC
(In reply to Navid Zamani from comment #7)
Oh, and with a black background, the outer glow would just be invisible. :)
Comment 9 Michael D 2018-02-20 01:57:27 UTC
Why not have configurable font color, or have the background detected and automatically select text color based on that (which I imagine is way harder to implement)?
Comment 10 Rog131 2018-02-20 07:07:27 UTC
(In reply to Michael D from comment #9)
> Why not have configurable font color, or have the background detected and
> automatically select text color based on that (which I imagine is way harder
> to implement)?

The Breeze plasma lockscreen is using plasma complementary color group. The Breeze text color can be set from the KDE system settings > Colors > Complementary > Normal text.

Image - Imgur: https://imgur.com/jrC4bR8
Comment 11 Navid Zamani 2018-02-20 14:04:57 UTC
(In reply to Rog131 from comment #10)
> The Breeze text color can be set from the KDE system settings > Colors >
> Complementary > Normal text.

That doesn’t actually work. I just changed that color from white to black, saved it as a new scheme, closed the dialog, selected my new scheme from the list, and clicked “Apply”. Then I locked the screen, and … nothing had changed.
Also, the white text isn’t actually fully white by default either.

And the actual full path is K → System settings → Colors → Change scheme → Color selection [tab] → Color set [dropdown] (Generic colors ⇒ Complementary) → Normal text.
(This is translated from German, so YMMV.)
You need to save the scheme as a new one, because the „Apply“ button inside the scheme editing dialog does nothing, and your changes will be lost otherwise.

Or do I need to restart something or log out once?

How did you make that screenshot by the way? The dialog is on top of the lock screen. Photoshop^WGimp, or is there a way to test the lock screen?
Comment 12 Rog131 2018-02-20 18:43:46 UTC
(In reply to Navid Zamani from comment #11)
> (In reply to Rog131 from comment #10)
> > The Breeze text color can be set from the KDE system settings > Colors >
> > Complementary > Normal text.
> 
> That doesn’t actually work. I just changed that color from white to black,
> saved it as a new scheme, closed the dialog, selected my new scheme from the
> list, and clicked “Apply”. Then I locked the screen, and … nothing had
> changed.
> Also, the white text isn’t actually fully white by default either.
> 
> And the actual full path is K → System settings → Colors → Change scheme →
> Color selection [tab] → Color set [dropdown] (Generic colors ⇒
> Complementary) → Normal text.
> (This is translated from German, so YMMV.)
> You need to save the scheme as a new one, because the „Apply“ button inside
> the scheme editing dialog does nothing, and your changes will be lost
> otherwise.
> 
> Or do I need to restart something or log out once?
> 
> How did you make that screenshot by the way? The dialog is on top of the
> lock screen. Photoshop^WGimp, or is there a way to test the lock screen?

KDE Forums - KDE Plasma lockscreen colors and testing lock screen: https://forum.kde.org/viewtopic.php?f=14&t=151172
Comment 13 Nate Graham 2018-03-16 16:36:24 UTC
I am attaching two exceptionally crude mockups of what we discussed in the VDG room this morning: in essence, the lock screen would display some background and the date/time by default. Then once you move the mouse, touch the screen, or show a key, a floating frame would appear showing all the UI controls. Basically this implements the "screen saver" paradigm, and resolved the usability issues brought up here.
Comment 14 Nate Graham 2018-03-16 16:38:26 UTC
Created attachment 111444 [details]
What you see right after the screen locks

This is what you would see immediately after the screen locks.

The date/time text would have a strong shadow behind the text to ensure that it shows up on very light backgrounds.
Comment 15 Nate Graham 2018-03-16 16:40:49 UTC
Also worth mentioning that we haven't decided for sure on what the default background will be. Current contenders are:
- Default Plasma wallpaper
- Slideshow of all the wallpapers in the wallpaper folder
Comment 16 Nate Graham 2018-03-16 16:41:17 UTC
Created attachment 111445 [details]
What you usee after any user input

And this is what you would see after any user input (moving the mouse, touching a touchscreen, hitting any key, etc): a floating window that contains all the UI elements. This window would inherit your user-chosen style, so for example if you were using Breeze Dark, it would have a dark background and white text.
Comment 17 Marco Martin 2018-03-16 16:56:18 UTC
that's another prototype i did
https://www.youtube.com/watch?v=BOsclMNpK3M

i'll try also a version which has the dialog appearing in the same way, tough i think i would prefer the wallpaper fading out either to a color or to a blur instead
(hironically the dialog one was pretty much the first design for the lock screen after vdg cchanged it to the black strip version)
Comment 18 Nate Graham 2018-03-16 17:01:47 UTC
> i'll try also a version which has the dialog appearing in the same way, tough i think i would prefer the wallpaper fading out either to a color or to a blur instead

+1 for blurring the current background once the window appears. I think that would look really, really good.
Comment 19 Marco Martin 2018-03-16 17:21:19 UTC
another version, with blur
https://www.youtube.com/watch?v=KWCZwrPXfVk
Comment 20 Michael D 2018-03-16 17:56:10 UTC
Just to chime in, I still prefer having everything visible always, with an option for changing the font color. Otherwise we might as well file another bug right now about how the white text is still unreadable on certain backgrounds before input.
Comment 21 Nate Graham 2018-03-16 17:57:24 UTC
Since this patch is all about poor text visibility on certain backgrounds, you can rest assured that we won't neglect that aspect of the design.
Comment 22 Michael D 2018-03-16 18:10:48 UTC
Great. In that case I have no complaints (except for the quibble that I still dislike unnecessarily hiding information in the name of aesthetic flair).
Comment 23 Michail Vourlakos 2018-03-16 21:18:41 UTC
(In reply to Marco Martin from comment #19)
> another version, with blur
> https://www.youtube.com/watch?v=KWCZwrPXfVk

Looks very good!
I just want to add some ideas in case they will help a bit more with the contrast between the background and the text color used when the background isnt blurred...

Latte demonstrated the following: https://www.youtube.com/watch?v=srkKkSnjG-w
watch out the top panel how changes its color...

The algorithm is the following:
1. For the underlying background is calculated the relative luminas only for the region of the background which is under the panel
2. That luminas value is cached so it isnt calculated again when we switch to that background
3. Based on that luminas value Latte is choosing between backgroundColor and textColor, the one that provides the greater contrast.
4. [based on another Latte part that I had to make similar design decisions]
  a. When a whitish color is used for the text then enabling shadows looks really good
  b. but when a darkish color is used for text then it is better to disable totally the shadows
Comment 24 Martin Flöser 2018-03-17 11:13:13 UTC
I really like the idea presented by Marco to use a slideshow and then transition to our "existing" lock screen. I see this as a clear evolution over the current state without losing why we did the current existing lock screen in the first place.

What I would like to be considered is the impact on the environment when doing a slideshow. If a system is locked, it's most likely because nobody is in front of the system. That means we show an animation nobody sees, which of course has a negative impact on the climate. We shouldn't downplay this factor as this change will hopefully affect millions of systems.

But I think it's possible to get a compromise here:
 * stop the animation as soon as the screen goes into power saving (for this we might need a hook from powerdevil) and restart on user interaction
 * increase the time between every transition (e.g. fibonacci style, so the longer nobody interacting with the system, the longer it takes for an animation to be shown).

For those wondering why an animation is a big deal: in the locked case we have KWin (Wayland compositor) pretty much sleeping, the system can go into the lowest power mode. But animations mean that the compositor is woken up and the system needs to go into a higher power state. The transition between wallpapers is animated so our system is at least woken up 60 times per second for the duration of the transition.
Comment 25 Rog131 2018-04-10 15:15:18 UTC
*** Bug 392964 has been marked as a duplicate of this bug. ***
Comment 26 Marco Martin 2018-04-22 14:41:19 UTC
Git commit 448455c3c937cebc1358dc417b280b0008a4c196 by Marco Martin.
Committed on 22/04/2018 at 14:41.
Pushed by mart into branch 'master'.

fade to blur when the login box appears

Summary:
for both lockscreen and login screen:

* display the wallpaper and the clock with a shadow by default
* at the first mouse or keyboard input, make the input fields appear
* the actual controls appear pretty fast
* the wallpaper starts to blur, desaturate and fade to darker
* after 10 seconds make the controls disappear again

* as soon as anything is written in the password field never fade out the controls
* if the virtual keyboard is open, never fade out the controls
* if anything is pushed on the stack, like "switch user", never fade the controls
* Esc clears the field and makes controls disappear (closing keyboard if needed)

the fade won't happen if the background is a simple color
Related: bug 388622
FIXED-IN: 5.13

Depends on D12314

Recommended D11309 and D11308 to change the default wallpaper to plasma wallpaper

Test Plan: tested the behavior of all the above points

Reviewers: #plasma, #vdg, ngraham

Reviewed By: #vdg, ngraham

Subscribers: zzag, abetts, davidedmundson, ngraham, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D11928

M  +4    -2    lookandfeel/contents/components/Clock.qml
M  +0    -1    lookandfeel/contents/components/SessionManagementScreen.qml
A  +182  -0    lookandfeel/contents/components/WallpaperFader.qml     [License: GPL (v2)]
M  +81   -13   lookandfeel/contents/lockscreen/LockScreenUi.qml
M  +2    -0    sddm-theme/Login.qml
M  +308  -236  sddm-theme/Main.qml

https://commits.kde.org/plasma-workspace/448455c3c937cebc1358dc417b280b0008a4c196
Comment 27 Pascal d'Hermilly 2018-04-23 07:05:45 UTC
Created attachment 112183 [details]
attachment-6928-0.html

Looks good. You can read the text with a white background, right?
I'm having trouble imagining the whole thing from the explanation. 

Den 22. april 2018 16.41.19 CEST, Marco Martin <bugzilla_noreply@kde.org> skrev:
>https://bugs.kde.org/show_bug.cgi?id=369676
>
>Marco Martin <notmart@gmail.com> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>             Status|CONFIRMED                   |RESOLVED
>         Resolution|---                         |FIXED
> Latest Commit|                            |https://commits.kde.org/pla
>              |                            |sma-workspace/448455c3c937c
>              |                            |ebc1358dc417b280b0008a4c196
>   Version Fixed In|                            |5.13
>
>--- Comment #26 from Marco Martin <notmart@gmail.com> ---
>Git commit 448455c3c937cebc1358dc417b280b0008a4c196 by Marco Martin.
>Committed on 22/04/2018 at 14:41.
>Pushed by mart into branch 'master'.
>
>fade to blur when the login box appears
>
>Summary:
>for both lockscreen and login screen:
>
>* display the wallpaper and the clock with a shadow by default
>* at the first mouse or keyboard input, make the input fields appear
>* the actual controls appear pretty fast
>* the wallpaper starts to blur, desaturate and fade to darker
>* after 10 seconds make the controls disappear again
>
>* as soon as anything is written in the password field never fade out
>the
>controls
>* if the virtual keyboard is open, never fade out the controls
>* if anything is pushed on the stack, like "switch user", never fade
>the
>controls
>* Esc clears the field and makes controls disappear (closing keyboard
>if
>needed)
>
>the fade won't happen if the background is a simple color
>Related: bug 388622
>FIXED-IN: 5.13
>
>Depends on D12314
>
>Recommended D11309 and D11308 to change the default wallpaper to plasma
>wallpaper
>
>Test Plan: tested the behavior of all the above points
>
>Reviewers: #plasma, #vdg, ngraham
>
>Reviewed By: #vdg, ngraham
>
>Subscribers: zzag, abetts, davidedmundson, ngraham, plasma-devel
>
>Tags: #plasma
>
>Differential Revision: https://phabricator.kde.org/D11928
>
>M  +4    -2    lookandfeel/contents/components/Clock.qml
>M  +0    -1   
>lookandfeel/contents/components/SessionManagementScreen.qml
>A  +182  -0    lookandfeel/contents/components/WallpaperFader.qml    
>[License:
>GPL (v2)]
>M  +81   -13   lookandfeel/contents/lockscreen/LockScreenUi.qml
>M  +2    -0    sddm-theme/Login.qml
>M  +308  -236  sddm-theme/Main.qml
>
>https://commits.kde.org/plasma-workspace/448455c3c937cebc1358dc417b280b0008a4c196
>
>-- 
>You are receiving this mail because:
>You are on the CC list for the bug.
Comment 28 Nate Graham 2018-04-29 13:05:28 UTC
*** Bug 367764 has been marked as a duplicate of this bug. ***