[SDDM theme] remove blur and increase UI contrast so that it's not required
AbandonedPublic

Authored by ngraham on Oct 7 2018, 9:05 PM.

Details

Summary

This patch adjusts the Breeze SDDM theme to remove the semi-permanently-blurred background, which has not been especially popular.

Adequate background contrast for the avatar was already added in D16879.

The buttons get better contrast by using new variants that include contrasting background circles from D15999. If these icons are not available, it falls back to the old ones, which is important for 3rd-party themes that will be using the old names and generally have their own backgrounds to solve the previous contrast problem.

The bottom row of icons get adequate contrast by putting a dark translucent bar behind them.

The net result is that the background image is now actually visible. But this does not come at the expense of usability since all the UI elements now get adequate contrast no matter what the background is.

Depends on D15999

BUG: 398115
FIXED-IN: 5.15.0
Closes T9658

Test Plan

Diff Detail

Repository
R120 Plasma Workspace
Branch
arcpatch-D16031_1
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 5528
Build 5546: arc lint + arc unit
There are a very large number of changes, so older changes are hidden. Show Older Changes

Why should the login screen look different to the lock screen?

Why should the login screen look different to the lock screen?

This is a response to user complaints about the login screen receiving the same blur used on the lock screen when the controls are shown. Since the controls are always shown on the login screen you get a blurry background on the login screen. Now if you are saying this looks good and we should now think about using it in place of the blur on the lock screen. I Think we could do that now since the main reason to use blur in the first place was to controls more visible.

Why should the login screen look different to the lock screen?

It already does. This patch arguably makes it less different in some ways. But as @rizzitello says, we've gotten a lot of user complaints about how the login screen permanently obscures the background image; it was prettier before. This patch is an attempt to solve in a different way the problem that drove the adoption of the blurry overlay, so that we can have both adequate readability and also an attractive background image.

I think the lock screen can stay the way it is because 1. people seem to like it and 2. with the current design, you can basically have a screensaver attractive animated lock screen background, which is popular and fun.

rooty added a comment.Oct 12 2018, 8:33 AM

Why should the login screen look different to the lock screen?

why not?

the lock screen (like nate said) is fine the way it is and the login screen had the problem of obscuring the login/password input dialog (which you need closer at hand than on the lock screen) + obscuring the background image (the lock screen doesn't really do that considering that most of the time the lock screen actually stays unblurred until you decide to unlock it)

why not?

Because it makes for a inconsistent random experience

The shadows look now better than in the first revision. Still I find the original version with full blur and darkened background way better to read for many background pictures. I don't think it's wort it to sacrifice this usability factor to allow a better view of the background.

Instead would it be possible to have a similar timeout for hiding the controls and unblurring as for the lockscreen (with visible controls and blur in the beginning)?

rooty added a comment.EditedOct 12 2018, 9:15 AM

why not?

Because it makes for a inconsistent random experience

perhaps, but a far more intuitive experience

unless you're about to add a Slide to unlock message to both screens (because without it, once the dialogs are lost, the user doesn't know that they can, in fact, log in) and tone down the blur without removing it

rooty added a comment.Oct 12 2018, 5:36 PM

why not?

Because it makes for a inconsistent random experience

p.s. :D i never wanted to do away with the blur in the first place, i think it's kinda cool, but it does kind of cloud out the wallpaper, i'm *all for* just diminishing the blur effect, and not doing away with it altogether

[Just as a reminder: this is only for the login screen; the lock screen is not being touched]

I wish the conceptual concerns had been brought up in T9658 before I started implementing the design changes we agreed to there. It has been open for a month and I tagged Plasma and VDG. If there is a better way to get people's attention, I'd like to know it.

Anyway, it's important that we remove the blur for aesthetic reasons. The blurry login screen background is the very first thing a new user sees, as well as what every existing user sees when they turn on their machine (regular people tend to turn their computers off when they're done with them, unlike us weirdos). We go our of our way to put the beautiful Plasma wallpaper there--only to ruin the effect by turning it into a dark blurry soup. User feedback has not been very positive, in contrast to the lock screen, which people love.

We also need to preserve readability, of course, as that was the major driver for implementing the blur. This patch aims to do it without blur. I'm open to suggestions, but the blur has got to go.

ngraham updated this revision to Diff 44876.Nov 4 2018, 11:40 PM
ngraham marked an inline comment as done.
  • Improve contrast for bottom buttons
  • Correct color names

[Just as a reminder: this is only for the login screen; the lock screen is not being touched]

I wish the conceptual concerns had been brought up in T9658 before I started implementing the design changes we agreed to there. It has been open for a month and I tagged Plasma and VDG. If there is a better way to get people's attention, I'd like to know it.

Without an example it was difficult to assess the visuals. This diff provides example pictures and it's difficult to read text and symbols on many of them.

Anyway, it's important that we remove the blur for aesthetic reasons. The blurry login screen background is the very first thing a new user sees, as well as what every existing user sees when they turn on their machine (regular people tend to turn their computers off when they're done with them, unlike us weirdos). We go our of our way to put the beautiful Plasma wallpaper there--only to ruin the effect by turning it into a dark blurry soup. User feedback has not been very positive, in contrast to the lock screen, which people love.

More important than aesthetics is usability. The ui elements are often difficult to see even with the shadows. Also imo it doesn't look aesthetically pleasing if the ui elements are not distinct to the background.

We also need to preserve readability, of course, as that was the major driver for implementing the blur. This patch aims to do it without blur. I'm open to suggestions, but the blur has got to go.

As said maybe we can have a similar timeout as on the lock screen. And directly after reboot we either hide controls or only show the user pic of the last logged in user plus the password field and on first input do blur + show other controls. Not sure what would work out in the end. But imo this solution proposal should go back into concept phase. Last word has VDG though. Is there consensus by VDG that this here is the solution to go with?

ngraham added a comment.EditedNov 5 2018, 3:58 AM

Yeah, I understand that it can be hard to visualize changes like these before there are pictures. Thing is, we're in a tough spot, because the current design turns the wallpaper into a soupy mess and generates user complaints. I agree that we shouldn't regress usability, but aesthetics are very important too. What's being proposed here is nothing more than a superior version of what we shipped from Plasma 5.8 - 5.12 (which is what I wanted all along during the 5.13 design changes but didn't get because we ran out of time before we had to ship something due to our very short release cycles).

Conceptually, when you have a contrast problem because the background is variable and the foreground isn't, you can put a window, frame, or artificial background under the foreground, or you can give the foreground an outline or a shadow. The early Plasma 5 login screen put a dark translucent rectangle underneath the foreground elements, which worked just fine:

I think this was actually a great design, because it ensured good contrast for the UI elements and labels, but allowed you to actually see most of the background wallpaper. Fast forward, and the 5.13 and later login screen does something similar by darkening and blurring the whole wallpaper, but it's a big visual regression because it obscures the entire background and makes it look like a swamp; there's practically no point in setting a wallpaper at all for the login screen since you don't see it in real-world workflows (i.e. the 50-second timeout doesn't count). If we reduce the darkness and strength of the blur to try to improve its aesthetics, we worsen the contrast that it generates. In other words, with the current design, we have no freedom of movement: if we improve one thing, it worsens another. Also, we don't actually resolve the user complaints by simple reducing the blur; people want to be able to see the wallpaper.

I think that in terms of visuals and usability, the pre-5.8 theme was just fine and there was no reason to replace it, but I wasn't around back then, so I don't know what concerns were in play at the time. Either way, that ship has sailed and we need to address the legitimate aesthetic concerns with the current login screen. This patch is an attempt to do that without regressing contrast too much (though I admit that some is inevitable), but it's still a linked system where improving one worsens the other. If we're not willing to accept this trade-off, I think we need to seriously consider bringing back a frame or window of some sort that we can put under the foreground, like the pre-5.8 style had. I'm very open to this option--in fact, it's my preferred solution--but the last time I brought it up, people didn't like that idea on the grounds that it was "dated" and "not very modern" (etc). Maybe we should re-open that discussion.

filipf added a comment.Nov 6 2018, 7:50 PM

But it seems to me like Nate's addressed or is addressing all the pitfalls regarding usability. The icons will have more contrast in a newer revision and from what I've seen in that diff there's an idea of adding a rectangle at the bottom to make the text there nicely legible. All the other textual elements seem just fine in my opinion.

Aesthetically perhaps it would be preferable to avoid the outlines around text, but if it helps legibility it's fine. Otherwise I don't think there is aesthetic degradation here - and if there is, not blurring the wallpaper will compensate for it. And the new revision of the icons in particular looks very classy.

The consistency argument actually seems like a stronger one here, but I don't see why the lock and login screens should necessarily be identical in design. You could use the circular icons in the logout and lock screen to help with this. The greatest consistency issue is more likely to be the SDDM theme disrespecting user customization, which is a different topic altogether.

My opinion doesn't hold much weight, but it seems to me that: there was plenty of time to discuss the idea in the respective task, that the current project is at the finish line and that the potential objections do not seem grave enough to warrant going back to the drawing board, especially if there is no defined proposal as an alternative.

ngraham edited the test plan for this revision. (Show Details)Nov 9 2018, 12:28 AM
davidedmundson requested changes to this revision.Nov 9 2018, 1:08 AM

Why are there hardcoded colours? If the font is black then surely the outline needs to be white?

There's two parts to this patch:

  • Improving readability on any background, blurred or not, on login/lock/logout.
  • Changing the login visually

The first part is non-controversial. They're iterative design changes. If you split it, I'll happily ship the 1st part (with hardcoded colours fixed)

sddm-theme/Main.qml
309

This is now choosing an arbitrary size and hoping the contents happen to be smaller.

Generally (if possible) you want views to fit contents, not squish contents to view.

i.e

height: theInnerLayout.implicitHeight

This revision now requires changes to proceed.Nov 9 2018, 1:08 AM

OK, will do!

rooty added a comment.EditedNov 9 2018, 6:19 PM

hey i just set up these revisions and i'm liking the new theme
one problem though, it seems as though Suspend, Restart, Shutdown are showing up as 12pt instead of 11pt or 10pt? it just looks a little too big compared to (when i force) 11pt

also would you consider changing the username font size to 12 pt?

filipf added a comment.EditedNov 9 2018, 6:32 PM

hey i just set up these revisions and i'm liking the new theme
one problem though, it seems as though Suspend, Restart, Shutdown are showing up as 12pt instead of 11pt or 10pt? it just looks a little too big compared to (when i force) 11pt

Yeah I also tested the latest revision (tried it out with my default font too) and have some concerns regarding the font sizes.

To expand a bit more on what you noticed:

a) technical aspect - the action button text and usernames actually seem to be showing up as 12pt, not 11pt for me as well. Even on my FHD laptop where I use 11pt fonts to scale the screen, this looks too big.

b) visual aspect - the login and password dialogs are still at 10pt and are now *sandwiched* between two 11pt(12pt?) texual elements (usernames and action button text). The "sandwiching" can make it noticeable that there is a discrepancy in font sizes, which in turn may not feel quite right aesthetically.

c) conceptual aspect - thinking conceptually, are the action buttons more important than the login and password box? Users probably mainly use the login screen to type in their password, but the action buttons kind of stick out more.

If I'm seeing it right and if you agree with me of course, this is what I see as potential solutions:

  1. keep everything at 10pt -> you remain true to the desktop default
  2. only have the usernames at 11pt -> you, in a way, avoid the visual discrepancy by not interrupting the vertical gradient of fontsizes whereby the fontsizes are decreased going from top to bottom
  3. switch all these central text elements to 11 pt (but not 12pt) -> hmm even at 11pt this may look too big for people with PCs, normal monitors and vision, but unfortunately I can't test this for quite some time :/
rooty added a comment.EditedNov 9 2018, 7:05 PM

hey nate would you consider changing all the #232629 outlines to #333333 (except for the footer)? they come out a little strong when set to #232629 imo and i think #333333 hits just the spot between too black (dark) and too white (bright)

I'm separating out all the potentially controversial changes into a separate patch (and will probably revert the font size changes; you guys are right about that). I might not have time until later tonight or sometime tomorrow evening since I'm single-parenting for a few days and my kids are both sick at the moment. Stay tuned.

rooty added a comment.Nov 9 2018, 10:41 PM

thanks! and good luck! sorry about the little ones hope they get well soon

rooty added a comment.Nov 10 2018, 9:44 PM

sorry to be a bore, but how do you guys feel about removing the outline and tinkering with DropShadow instead? i set it to:

radius: 12
samples: 32
spread: 0.35
color: Qt.rgba(0, 0, 0, 1)

and this is what happens on top of a very messy bright background


not there yet but worth considering? is it too weak? also, i didn't modify the clock (not sure if it really benefits from greater "spread")

@davidedmundson I've put only the fairly non-controversial changes into D16879.

rooty added a comment.EditedNov 19 2018, 8:03 AM

People have been complaining about the blur, but is it necessary to do away with it, or is it a better idea to run with it like they do in Windows Fluent Design (Deepin too actually)?

This theme, for example, has different blur that might work (It makes you think you need glasses though).
It's a Breeze-Chili hybrid that incorporates the proposed font changes into ActionButton.qml and UserDelegate.qml. I'm just not sure about the shadows behind the clock (spread: 0.1) but they look great full screen. It also uses Chili's password box (even though I do like the Breeze one, not really sure about that). I haven't yet incorporated the latest system.svgz icons here though, because they look sort of out of place on top of a blurry background.

Thing is, if we're going to reduce the blur that much, why not just show the original image?

People have been complaining about the blur, but is it necessary to do away with it, or is it a better idea to run with it like they do in Windows Fluent Design (Deepin too actually)?

This theme, for example, has different blur that might work (It makes you think you need glasses though).
It's a Breeze-Chili hybrid that incorporates the proposed font changes into ActionButton.qml and UserDelegate.qml. I'm just not sure about the shadows behind the clock (spread: 0.1) but they look great full screen. It also uses Chili's password box (even though I do like the Breeze one, not really sure about that). I haven't yet incorporated the latest system.svgz icons here though, because they look sort of out of place on top of a blurry background.

These are fairly appealing blur settings, but yeah, if we're still leaving blur on the table, it should be proper blurring. I liked the one in Deepin for what it's worth:

rooty added a comment.EditedNov 19 2018, 9:51 PM

Thing is, if we're going to reduce the blur that much, why not just show the original image?

That's a fair point.
Another fair point: Why not just pick an image that doesn't really interfere with the boxes and icons that much then you don't need blur at all.

That being said, I personally prefer blur - it's just a matter of taste. The added bonus with the blur is the "effect" or "animation" (more like, the time needed for it to show up and disappear later on). Not to belabor the point (too much) but I've also been using ImageSplash (a splash screen that uses an image instead of an actual splash screen) to bridge the gap between the login screen and the desktop, and you get a very smooth transition from login to desktop with both blur and non-blur when it disappears (and my graphics drivers decide not to glitch), check it out you might like it:

Might be something worth investigating,

Sorry about the bad video quality and my fairly unsteady right hand.

Another fair point: Why not just pick an image that doesn't really interfere with the boxes and icons that much then you don't need blur at all.

Because within reason, it's the system's job to accommodate the user, not the reverse.

rooty added a comment.EditedNov 19 2018, 9:56 PM

Another fair point: Why not just pick an image that doesn't really interfere with the boxes and icons that much then you don't need blur at all.

Because within reason, it's the system's job to accommodate the user, not the reverse.

No, I mean, I did phrase it in the 2nd person but I was talking about KDE picking a wallpaper that's appropriate/suited to the login environment. One of the things that blur does really well is make it idiotproof so wallpaper selection isn't as much of an issue (however it does sort of butcher the wallpaper).

If done tastefully it can preserve the wallpaper and help our cause at the same time imo

ngraham updated this revision to Diff 46475.Nov 29 2018, 2:38 PM

Remove changes that were made in D16879

ngraham updated this revision to Diff 46477.Nov 29 2018, 2:44 PM

Rebase on master and fix merge conflicts

ngraham edited the summary of this revision. (Show Details)Nov 29 2018, 3:36 PM
ngraham updated this revision to Diff 46518.Nov 29 2018, 11:26 PM

Don't hardcode colors

ngraham updated this revision to Diff 46519.Nov 29 2018, 11:29 PM

Calculate footer background bar height correctly

ngraham marked an inline comment as done.Nov 29 2018, 11:29 PM
ngraham edited the test plan for this revision. (Show Details)Nov 30 2018, 3:25 AM
ngraham updated this revision to Diff 46522.Nov 30 2018, 4:04 AM
  • Use consistent shadows for ActionButton labels
  • Don't unnecessarily increase ActionButton label size
  • Don't unnecessarily add outlines around ActionButton labels (left over from earlier experiment)
ngraham updated this revision to Diff 46523.Nov 30 2018, 4:11 AM

Remove now-unnecessary import

ngraham edited the test plan for this revision. (Show Details)Nov 30 2018, 6:40 AM
raddison added a subscriber: raddison.EditedNov 30 2018, 1:40 PM

Still I find the original version with full blur and darkened background way better to read for many background pictures. I don't think it's wort it to sacrifice this usability factor to allow a better view of the background.

I think the same. Sacrificing the blur would result in dullness without any significant benefit.

Instead would it be possible to have a similar timeout for hiding the controls and unblurring as for the lockscreen (with visible controls and blur in the beginning)?

Yep, that would be great because it would result in a cohesive visual experience.

@romangg +1

Still I find the original version with full blur and darkened background way better to read for many background pictures. I don't think it's wort it to sacrifice this usability factor to allow a better view of the background.

I think the same. Sacrificing the blur would result in dullness without any significant benefit.

Instead would it be possible to have a similar timeout for hiding the controls and unblurring as for the lockscreen (with visible controls and blur in the beginning)?

Yep, that would be great because it would result in a cohesive visual experience.

@romangg +1

I addressed all of that already: https://phabricator.kde.org/D16031#354282

Still I find the original version with full blur and darkened background way better to read for many background pictures. I don't think it's wort it to sacrifice this usability factor to allow a better view of the background.

I think the same. Sacrificing the blur would result in dullness without any significant benefit.

Instead would it be possible to have a similar timeout for hiding the controls and unblurring as for the lockscreen (with visible controls and blur in the beginning)?

Yep, that would be great because it would result in a cohesive visual experience.

@romangg +1

I addressed all of that already: https://phabricator.kde.org/D16031#354282

@ngraham Is it going to look something like that? https://phabricator.kde.org/file/data/zaerjwktbynwubnvu3ja/PHID-FILE-y52h6nwujyugxuqkc73z/maxresdefault.jpg

No, screenshots for the current proposal are in the Test Plan section of this patch. The image you're referring to was the old Plasma 5 design that was replaced in Plasma 5.8. I would support going back to that style of design because it solves virtually all of the problems here. But so far there doesn't seem to be a lot of enthusiasm for that. The

raddison added a comment.EditedNov 30 2018, 5:00 PM

No, screenshots for the current proposal are in the Test Plan section of this patch. The image you're referring to was the old Plasma 5 design that was replaced in Plasma 5.8. I would support going back to that style of design because it solves virtually all of the problems here. But so far there doesn't seem to be a lot of enthusiasm for that. The

Truth to tell neither am I enthused about the old Plasma 5 design.
I've also looked at the test plan and it's not exactly a stroke of genius if it looks like https://phabricator.kde.org/file/data/w3iyc7eov3ys6kmhrwi7/PHID-FILE-nya3nyqpjbmnijijvlwm/Screenshot_20181129_233236.png

I need some time to tinker.

I've also looked at the test plan and it's not exactly a stroke of genius if it looks like https://phabricator.kde.org/file/data/w3iyc7eov3ys6kmhrwi7/PHID-FILE-nya3nyqpjbmnijijvlwm/Screenshot_20181129_233236.png

You have two options:

  • Stop insulting people and their work
  • Go away

Coming up with realistic solutions to difficult and controversial issues is hard. We have gone over a bunch of different designs and all of them have strengths and weaknesses. You are welcome to propose alternatives in T9658, but please do it with respect. Thanks.

raddison added a comment.EditedDec 3 2018, 8:50 PM

I've also looked at the test plan and it's not exactly a stroke of genius if it looks like https://phabricator.kde.org/file/data/w3iyc7eov3ys6kmhrwi7/PHID-FILE-nya3nyqpjbmnijijvlwm/Screenshot_20181129_233236.png

You have two options:

  • Stop insulting people and their work
  • Go away

    Coming up with realistic solutions to difficult and controversial issues is hard. We have gone over a bunch of different designs and all of them have strengths and weaknesses. You are welcome to propose alternatives in T9658, but please do it with respect. Thanks.

@ngraham With all due respect I have not insulted anyone or anything. I have expressed my point of view with regard to a thing and not a person. Why is it needed to fix something that is already the best possible solution? You have also stated that the desktop has to adapt to the user and not the other way around. Very generous concept but unrealistic. As things stand right now, the login in Plasma is at least on par if not better than what Windows, Deepin or Android have. Blur + a tint of dark make the controls perfectly visible, even if the background is very bright or white. The same holds true for both the lock screen and the login screen. You have also stated that people are complaining about the login/lock screens without quantifying their complaints in any way whatsoever (e.g. satisfaction/dissatisfaction ratio?). Which is a methodological flaw. Your argument boils down to "I want to see the wallpaper". Fine.

Whether we are talking about the login screen or the lock screen, things are similar.

You only see the blurred + slightly tinted login or lock screen for a very brief span of time (when you log-in). At all other times you can see the wallpaper or the wallpaper with a date and time. If auto login is disabled you will boot into the login screen but after a brief span of time (set by default or the user) the login screen will time-out into a wallpaper with a date and time. At that moment, if you move the mouse, the login screen will show up but as soon as you stop interacting, the login screen will time-out again. I'm uploading some screenshots in defense of what I think to be a masterpiece of Plasma that shouldn't be tempered with then I'll rest my case. I should have used Neon but Solus Plasma will do just fine.

Kind regards, my friend. I have nothing but positive feelings towards you and your hard work is worthy of our admiration. I'm blunt, yes, but no insult whatsoever had been intended.

rooty added a comment.EditedDec 3 2018, 9:07 PM

You have two options:

  • Stop insulting people and their work
  • Go away

naaate you're taking all of this way too personally
first of all, @raddison's got a point, these changes to remove the blur introduce a lot of new problems (the blur made sure that the text on the screen was always legible regardless of the wallpaper chosen (and how badly it got butchered))

he also touched on a very interesting argument you seem to invoke as justification for these changes, i.e. people have complained. i can't help but wonder if the idea to remove the blur came from somewhere else instead:

(dark shaded disks/circles included)

personally, i preferred the high sierra version of the login screen and i think it would look amazing if we went with that

just because people have been complaining about the blur doesn't mean we should do away with it altogether

@raddison You described my work as "not exactly a stroke of genius." That's not being "blunt", it's an insult. We have had this conversation before. I will be forwarding this and earlier exchanges to the KDE Community Working Group.

@rooty If you are implying that I want to remove the blur from the Plasma login screen because apparently Apple did it in macOS 10.14, you would be wrong. I didn't even know they did that until you brought it up right now.

I want to remove the blur from the login screen because it obscures the wallpaper and I think looks ugly (too dark, too blurry). The current design was not something we agonized over and polished forever; it was the best we could do to land a good design that was 95% done in the 5.13 timeframe before we would have otherwise missed the release.

As I have mentioned a couple of times, I am open to discussing alternative designs that make the wallpaper mostly visible like this patch does, while offering improved background contrast for the text and controls. I have offered up the Plasma 5.7 and earlier login screen design as one such example that I think worked well to accomplish both of those goals by using a dark background/frame underneath the UI controls. The current darkened blur solution basically does the same thing, but regresses the visuals by unnecessarily extending it to the entire screen--most of which has no UI controls on it, so it's not needed. There's no point in even having a wallpaper on the login screen if it's not going to be visible with the current darkened blur. We might as well just make it a solid dark gray background. If you keep the blur but turn down the intensity and degree of darkening, you regress its ability to generate contrast against arbitrary backgrounds, and wind up with the worst of all worlds: poor contrast, and a wallpaper that still isn't visible.

rooty added a comment.Dec 3 2018, 9:40 PM

so i take it you're open to the idea of an unobtrusive type of blur?
i get that you want to preserve the wallpaper, but sometimes it really does get in the way (snow, mountains, clouds, etc.)

I don't see the point of an "unobtrusive blur." As I said, if we make the blur less extreme (less blurry, less/no darkening), then we return to having contrast problems with light or visually busy backgrounds. We add that problem back without solving the one here (the wallpaper is obscured).

BTW the macOS 10.13 lock/login screen "mild blur" works because it's showing you a blurred version of whatever your actual desktop wallpaper is, so there's continuity between the lock/login screens and the desktop experience. There's never a time when you only see a blurry version of something and never the real version.

That's not a feature we have; the wallpapers of the lock screen, login screen, and desktops are all independent. Whether or not this is desirable is an entirely different issue, but operating with the limitation of not having that, there is no point to a "mild blur" on the login screen because it's not a hint of anything else; it's just a blurry image.

rooty added a comment.EditedDec 3 2018, 10:08 PM

That's not a feature we have; the wallpapers of the lock screen, login screen, and desktops are all independent. Whether or not this is desirable is an entirely different issue, but operating with the limitation of not having that, there is no point to a "mild blur" on the login screen because it's not a hint of anything else; it's just a blurry image.

I actually toyed with this idea by introducing ImageSplash (instead of the KDE splash screen) and making the transition from login screen to desktop seem seamless (no interruption between login and desktop). Also, if you'd pick a different user, the login screen would just fade out and switch to that user's wallpaper (again, very tastefully). Unfortunately Kwin (I think it was Kwin) likes to flicker on my computer (not every time though...) right before the panel pops up, so... it wasn't so much seamless as almost seamless.

raddison added a comment.EditedDec 5 2018, 11:17 AM

This patch adjusts the Breeze SDDM theme to remove the semi-permanently-blurred background, which has not been especially popular.

@ngraham Please produce methodological evidence of its unpopularity.

alexde added a subscriber: alexde.Dec 5 2018, 12:56 PM
This comment was removed by alexde.
filipf added a comment.Dec 7 2018, 4:05 PM

@ngraham I know this is going back to the dependent revision, but what do you think about maybe tightening the shadows around the clock?

Currently the shadows can look a bit blobby, and because the radius is so wide, the interior textual elements get filled up with black (see number "8")

If we do something like h.offset: -1, v.offset: -1, radius: 6, samples: 14, spread: 0.3) we get:

I think in most cases it doesn't present a legibility downgrade, but not sure about the nastiest outlier wallpapers.

but I don't see why the lock and login screens should necessarily be identical in design

I do. The the login and lock screens should be visually consistent with each other. It's a no-brainer. How do we mitigate that?

filipf added a comment.EditedDec 9 2018, 3:52 PM

but I don't see why the lock and login screens should necessarily be identical in design

I do. The the login and lock screens should be visually consistent with each other. It's a no-brainer. How do we mitigate that?

It's far from being a no-brainer. There is a temporal and functional difference between the two screens. The user will spend only a very short amount of time within the login screen, whereas a lock screen may stay on the screen longer. The user will also use the SDDM predominantly just for logging in, whereas the lock screen is functionally more diverse - offers some control (e.g. media playback) over and insight (e.g notifications) into the machine.

Allow me to show an example: what is the point of having a huge centered clock in the login screen? It would make more sense to, for instance, jam it down into the newly created panel in order to simply have SDDM focused on what it's supposed to do: log you in. This is why some environments such as Windows, Deepin or GNOME don't have a big clock in the login screen, but have one in the lock screen; they were most likely thinking about conceptual differences instead of just advocating visual consistency solely for visual consistency's sake.

On the other hand, having a big clock actually makes sense on the lock screen if I'm working on something next to my computer and I want to check the clock.

raddison added a comment.EditedDec 9 2018, 3:52 PM

ngraham wrote:

I think this was actually a great design, because it ensured good contrast for the UI elements and labels, but allowed you to actually see most of the background wallpaper.

@ngraham I now think that you were right. With some touch-ups we could turn it into an elegant solution, provided we don't break visual consistency between the login and lock screens.

PS: So essentially but non-restrictively the same design for both the login and lock screen, as illustrated in the above concept, is what I'm pleading for.

What do you guys think?

I think I'll have to use Gimp. When is the deadline? :)

raddison added a comment.EditedDec 10 2018, 12:19 PM

but I don't see why the lock and login screens should necessarily be identical in design

I do. The the login and lock screens should be visually consistent with each other. It's a no-brainer. How do we mitigate that?

It's far from being a no-brainer. There is a temporal and functional difference between the two screens. The user will spend only a very short amount of time within the login screen, whereas a lock screen may stay on the screen longer. The user will also use the SDDM predominantly just for logging in, whereas the lock screen is functionally more diverse - offers some control (e.g. media playback) over and insight (e.g notifications) into the machine.

Allow me to show an example: what is the point of having a huge centered clock in the login screen? It would make more sense to, for instance, jam it down into the newly created panel in order to simply have SDDM focused on what it's supposed to do: log you in. This is why some environments such as Windows, Deepin or GNOME don't have a big clock in the login screen, but have one in the lock screen; they were most likely thinking about conceptual differences instead of just advocating visual consistency solely for visual consistency's sake.

On the other hand, having a big clock actually makes sense on the lock screen if I'm working on something next to my computer and I want to check the clock.

"no-brainer" was referring to advisability, desirability and expectancy and not implementability. Visual consistency is advised, desired and expected and it can only be achieved upstream. The following exchange proves it:

The prettiest login theme I've seen, but I have a problem...

The behavior you are mentioning is not a "problem" but rather a misunderstanding of how KDE works. Let me explain:
The login theme you can download via system settings is a customization of a program called SDDM, which is completely independent of any desktop environment (which is KDE). The themes here on opendesktop or other platforms are specifically programmed for this program/application/software or whatever you want to call it (SDDM).
When you suspend your PC the KDE Plasma desktop environment calls a programm called KScreenlocker which forms part of the KDE desktop environment itself. This program (at least for the moment) has no means of customization through theming. It can be hard coded by reprogramming system files of the KDE suite but it will be overwritten any time you update your desktop environment.
I understand the inconvenience this causes because I too and other users before would love to unify the lockscreen with the login theme. For the moment I have to tell you that I'm sorry this is not possible as of now.

source: https://store.kde.org/p/1214121/

As far as implementability is concerned, visual consistency and functionality are equally important. You have however pointed out a number of important aspects and I thank you for that.

The lock and login screens are already subtly inconsistent with one another, so changing that isn't currently on the table.

Please keep the comments relevant to this patch. If you want to discuss conceptual issues, please do it in the Phab task (T9658) or elsewhere. Thanks.

filipf added a comment.EditedDec 11 2018, 10:25 PM

I have a question regarding legibility, something I've just stumbled upon in my tests.

What happens if there is more than one user? Will the label of the non-selected user be legible enough? UserDelegate.qml sets the opacity of this label at 0.5 so it may be tricky with some wallpapers.

ngraham updated this revision to Diff 49408.Jan 13 2019, 8:13 PM

Rebase on master and fix merge conflicts

ngraham planned changes to this revision.Jan 13 2019, 9:36 PM

After much discussion in the VDG room, we decided to put this on hold and revisit it for 5.16. The problem here is that we're worried that this change won't be enough to stop people from wanting to redesign it yet again, and we don't want to produce change fatigue here. We're going to focus on producing a timeless design that's good enough that nobody wants to redesign it anymore, which is ultimately the best sign that you have the design right.

rooty added a comment.EditedJan 13 2019, 9:40 PM

After much discussion in the VDG room, we decided to put this on hold and revisit it for 5.16. The problem here is that we're worried that this change won't be enough to stop people from wanting to redesign it yet again, and we don't want to produce change fatigue here. We're going to focus on producing a timeless design that's good enough that nobody wants to redesign it anymore, which is ultimately the best sign that you have the design right.

agreed

by the way, we might get an idea by/from revisiting old sddm themes too

ngraham abandoned this revision.Jan 13 2019, 10:16 PM

Yes, I think the old Plasma theme was great. It was changed as part of the "Boot to Shutdown" initiative (T2062) which in retrospect must be counted as a failure. It turned out to be not implementable according to the original design due to technical impediments, and what resulted from the effort anyway did not prove popular with users. We've been sort of incrementally reverting parts of it over the past year or so, but without any specific design in mind.

I think that's why this particular design never seemed to come together. With the original design, the elements all float above a blue background. But the blue background was ugly and unpopular and people replaced it with wallpaper. This looked pretty but introduced contrast problems. So we put the wallpaper there by default and blurred it to ensure contrast, but that defeated the purpose of adding the wallpaper since you couldn't actually see it! So now we get user complaints that they can't see the wallpaper on the lock screen and that it looks like a dark muddy mess. In this patch I removed the blur and tried to solve the contrast problems with a combination of drop shadows, new icons with built-in backgrounds, and a bottom bar, but the result never felt cohesive and our designers kept trying to redesign it over and over again--a sign that it still wasn't right. It started to feel like a game of whack-a-mole.

The root of the problem is that with this basic design, all the different elements want to hover over the background, unconstrained by a box or frame. This requires tight control over the background which in practice doesn't work since it's user-customizable and limits our own design choices (e.g. we could never use a light-colored wallpaper since then the text and icons would be illegible).

What I think we need to is come up with a new design that accommodates arbitrary backgrounds from the start, probably by putting all the UI elements in some kind of box, like the Plasma ≤ 5.7 theme, Elarun theme, Maldives theme, etc. And most importantly, they should feel good in a box or frame. it shouldn't feel like they're uncomfortable together, like they want to escape.

There's no time left for 5.15; let's give it a shot in 5.16 timeframe, with an eye towards producing something timeless that does not work against itself. Only then will our users feel satisfied and our designers will stop trying to redesign it. :)