In T12622#251704, @ngraham wrote:

The new "Quick Settings" landing page KCM (https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/348) in Plasma 5.22 now includes a button to take you to the config window of the current containment, which includes the wallpaper chooser. So the discoverability aspect of this task is now taken care of without technically making embedding it into System Settings as a KCM.

The mockups are a bit confusing to me, especially if I am using Krunner to find KCM pages... There are 2 entries named "Login screen" and also 2 named "Lock screen". One of each inside Background, which only lets you set the lock/login wallpaper, and it doesn't have an option to span over multiple monitors (while the desktop wallpaper has that option), and one of each in a totally different category, letting you set the activation time, media control and notification settings for the lockscreen, and the theming, autologin and powerbutton settings for the login screen... Wasn't the point of integrating lock screen and login screen background options with desktop wallpaper options to get rid of 3 separate places to set a wallpaper?

In T12622#232756, @zamundaaa wrote:

where just clicking configure on the actual wallpaper one needs to change requires no mental mapping, it's just there.

The configure button on the desktop doesn't have to go away - I imagine it should be possible to pre-select that screen when opened from a specific monitor. That way the intuitiveness of setting the wallpaper on a specific monitor stays and at the same time we get the ability of setting multiple monitors to a wallpaper at the same time, a UI for stretching the wallpaper over multiple monitors and the UI for setting the wallpaper for login and lock screen all in one, and all in the system settings where many users expect important settings like this to be.

My two cents here:

In T13012#228360, @squeakypancakes wrote:

In D29798#672261, @ngraham wrote:

You're probably right. This was a pretty lazy patch.

The inherent challenge here is that desktop wallpapers are per-containment ("Containment" means a screen or activity), while the lock and login screens are per-session. A further complication is that the login screen is only able to display still images (though maybe that could change?). So there isn't a super clean way to have a single config UI work for everything.

One thing I could imagine would be the following:

We make a new KCM in System Settings called "Wallpaper". This KCM essentially displays the current desktop wallpapers UI with one exception: it has multiple Apply options:

• Apply to desktop (shown when there is only one containment)
• Apply to current desktop (shown when there is more than one containment)
• Choose which desktops to apply it to (shown when there is more than one containment; needs a clever UI)
• Apply to all desktops (shown when there is more than one containment)
• Apply to lock screen (always shown)
• Apply to login screen (always shown, but only enabled when the chosen wallpaper is a still image)
  
  Maybe a sheet with these options could appear when you click on the Apply button. They would each be checkable, so you could apply the wallpapers to everything all at once if you wanted to.
  
  This is similar to how most smartphones handle this (as well as GNOME as of a recent version IIRC) and I think it works pretty well there.
  
  Thoughts?

And the result would be similar with other apps. The only edge-case left now is a VM with corner interaction (like Plasma's Screen Edges) running in windowed mode.
I guess the best practice would be to add a setting to enable round corners, maybe even tweak the radius, in the System Settings > Application Appearance > Window Decoration page, maybe as a 'Tweaks' tab (that would also display the settings currently accessed by clicking the pencil icon in the grid view), or include it in the settings window of the decoration, or just a slider at the bottom since there is already border size there.
And add a setting for this in the Window Rule settings window, so it can be turned on/off for specific windows.
Common VM apps could be added to the blacklist by default.
Tiled and maximized windows should have no round corners. Or maybe include a setting for that too. (There could be a button in the bottom bar of the Window Decorations page, named "Corner preferences" or "Corner radius" which would show a popup or an inline expansion overlay to configure the radius of corners, the tiling/maximized behaviour and maybe a link to window rules, something along these lines.)
Also care must be taken to exclude any window that Plasma might show (popups, menus, the Leave screen, Application Dashboard, panels, Latte panels), which aren't real windows.

In T10891#226931, @davidre wrote:

Konsole is a frequently used and core KDE application. That can have content (part of the first letter) in the corner depending on the window size.

In T10891#224633, @paulm wrote:

occasionally there may be content in the corner too.

In T10891#224536, @ngraham wrote:

I would like to do that--though maybe just a bit. However what I really want is rounded bottom corners when there are no borders, which would bring it into consistency with the topcorners. This would require having the window manager clip a few pixels from the window's content, which I know is heresy and sacrilege to some, but I genuinely don't see that it's actually a problem at all.

In T10891#224470, @manueljlin wrote:

It looks really nice but that will make GTK apps a bit inconsistent :c

I think that these settings (which screens, activities, lock/login screen, etc) should only appear when the user tries to apply a wallpaper, or maybe there could be an "Advanced" or "Preferences" button under the grid view. Having them up constantly would be kinda cluttered, especially on smaller windows or lower resolutions. It would take way too much space from the grid to have them there constantly. We could possibly make it work by having an adaptive layout that hides these settings behind a button or tab when only 2 grid rows or less would remain, and show them when there is plenty of space. In the "collapsed" window, only the wallpaper provider dropdown, its settings and the grid view would be present, with the "Add image" and "Get new wallpapers", "Preferences" and "Apply" buttons.

If I may chime in, I don't consider the elementary dropdown a great experience. Text is way too small and you get the grid behind it, When the search isn't instantaneous (and for many people and in many cases it isn't) it looks weird. Then as the search traverses the filesystem and new results show up, it resizes, creating visual clutter and overwhelms the user's mind. It would possibly be better to use the grid view as a search. Clicking on "back" or the now active Search button or pressing Esc would cancel the search and the grid, along with the addressbar would revert to the folder it was on before the search. To show results in their folder, the user would right-click, and that folder would become the path shown in the top bar. Also right-clicking it would yield an option to copy the path. If it is search now, it can't be edited with one click. Now to edit the path directly, the user would need a separate Edit button or a right-click enry on the pathbar to edit it.
I think it is important to keep the content frame and the pathbar consistent (displaying the same thing) in order to avoid confusion and potential havoc. The pathbar should show the path of the folder that the grid shows, and the grid should adapt to the pathbar if it is changed or a search is happening.

In T12622#219490, @ngraham wrote:

That proposal sounds pretty great to me, @kkoma! Is this something you would be interested in working on?

Hello, my two cents here:
What I would do is make a "Wallpaper" menu item in Settings, under the "Appearance" category. There would be a wallpaper plugin dropdown at the top, with the fitting GHNS button. Below would be a grid if the plugin supports it, or a placeholder text if it doesn't (like in case of Picture Of The Day), along with the settings of the specific plugin.
In a grid view, hovering a wallpapaer would show a larger preview with author and title, and 3 buttons: "Show in Dolphin" (folder icon), "View on KDE store" (maybe a link? Or a globe icon?), and "Remove" (red minus sign or trashcan, turning into the "Revive" button that is in use currently). This preview wouldn't have to cover more than 0.4 neighbouring grid items in each direction.
Below the grid would be the "Add image" and "Download new wallpaper" buttons.
Clicking "Apply" would bring up a dialog, asking where to apply:

• "Screens:" (as many rectangles as the number of screens follow. If one is clicked, it becomes highlighted, signaling that it is selected. The boxes have the proportions of the actual screens, like in Display configuration module. The current one is preselected.)
• "Activities:" (as many rectangles as the number of activities follow. Each has the activity icon on it. Clicking them selects them.
• "Lock screen" (checkbox)
• "Login screen" (checkbox with key icon signaling the need for elevated privileges)

If there is only one screen, the screen row would not be displayed. If there is only one activity, the activity row would not be displayed.
The dialog would also have a "Cancel" button. The dialog would show up for every wallpaper plugin.

In T12433#217724, @ngraham wrote:

There's another category of user you're missing: the productivity user. This person uses their computer for work. This person may or may not be a technical expert, but they know more about their computer than the novice. Because this person's computer is a work machine, they have better things to do than tweak things. This person is sensitive to good defaults and wants to be able to turn on the machine and immediately get to work. They may customize some things, but the customizations are more likely to be functional than visual. Because of this, if they go to customize something but find a huge number of visual tweak settings, they will get frustrated.

In T12517#217367, @ngraham wrote:

In general I agree with you, as long as we keep it very subtle. I think the password wiggle is a great example (BTW the "you enter the wrong password" timeout is currently 3 seconds so this wouldn't slow down anything).

I don't think using animations as explicit instructional tools is a good idea though. I think they're best used to communicate where something is going to or coming from, or to make it less jarring when something just appears. Overusing animations will make people who are already kind of leery of them adopt a hardline position and hate all of them. :)

In T12517#217305, @safaalfulaij wrote:

I believe anything that is as subtle as Firefox animations* is fine. Anything beyond must be killed (shredding flying moving scaling rotating etc etc).

Nowadays pretty much all GTK3 themes have a GTK2 version, but a few years ago (and there is a good chance of some people using old themes) there were many that didn't have one. There could be also in-development GTK3 themes in use, that don't yet have a GTK2 version.

In D18078#398771, @filipf wrote:

In D18078#398570, @ngraham wrote:

Where are we with replacing one of those flower images with another one?

We could add one more cityscape instead:

https://unsplash.com/photos/n_0jH_ttsvo

Or maybe restore @rooty 's fave grassland:

https://unsplash.com/photos/qxCqkbF7tUc

Orrr use this desert photo I sort of like due to its cleanliness (not @rooty though):

https://unsplash.com/photos/d_SO6cXpYEA

As for implementation, I take it we should wait until 5.17 since there will be no save cache prior to 5.16?