Yes please.

However see previous discussion of this at https://bugs.kde.org/show_bug.cgi?id=391485. Personally I think we should revisit the issue.

An option to sync/set wallpaper (settings) automatically for login and lock screen would be nice too.

In T12622#219390, @mmustac wrote:

An option to sync/set wallpaper (settings) automatically for login and lock screen would be nice too.

https://bugs.kde.org/show_bug.cgi?id=367666 :)

BTW, as supporting evidence that the status quo does indeed present a usability issue, I have been collecting user stories from people who have had trouble figuring out the default wallpaper. Here's what I've got so far just from Reddit:

• https://www.reddit.com/r/kde/comments/a23veb/how_do_i_change_the_wallpaper_and_lockscreen/
• https://www.reddit.com/r/linux/comments/ee2qjj/this_week_in_kde_its_gonna_be_amaaaaaaaaaaazing/fbr53jd?utm_source=share&utm_medium=web2x
• https://www.reddit.com/r/kde/comments/ewlve0/configuring_kde_plasma/
• https://www.reddit.com/r/Kubuntu/comments/8sa1bi/kubuntu_rules_best_linux_flavor_for_a_strong/

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.

I would consider moving the FolderView / Desktop option into a checkbox entry in the right-click menu: "Icons on desktop" and if it is checked, a "Folder View preferences..." entry would be added. The now deprecated "Desktop Preferences" entry would be replaced with "Set Wallpaper..."

Maybe DBus could be used to make it aware of the containment layouts...?"

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

In T12622#219490, @ngraham wrote:

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

I very much would be. I just have to learn C++ and Qt and Kirigami and QML first 😅. I am starting my second semester at Budapest University of Technology and Economics next week. I am studying Electronical Engineering there. We will learn C++ in that semester. I could try to learn the rest on my own during the semester; any help would be appreciated (guides, tutorials, good websites that teach these, examples, docs; anything), and then maybe do it in the summer, possibly GSoC or something like that.
I think I am up to it, but I have to learn first how to do it. I wanted to contribute actively to KDE for a long time, I just didn't have the necessary knowledge.

If I can help in non-coding parts, that would be even greater. Testing, translation, iconography, mockups, bug hunting and triaging, etc.

Btw the "larger preview with actions when hovering over an item" is a concept that could be made use of throughout KDE in grid views. So there would be an unified Kirigami element for that, and future apps could use it.

• The preview shows up if the mouse stops on an item (after some time, say 700ms)
• It is an opaque frame (same colour as view background, or maybe a bit lighter) with shadows. It appears and disappears through a fade animation.
• The actual preview rectangle is a larger version of the item, and transitions from it with a scaling animation. For wallpapers, that would also mean a higher resolution version is used for the large prview than the grid item, in order not to lose detail.
• Some details about the item (name, title, description, etc) and 1-4 icon-only action buttons would be displayed outside the actual preview rectangle, but in the overlay preview frame.
• The frame shouldn't occupy more than half of each surrounding item in the grid.
• When the mouse stops for 700ms on another item in the grid, the preview fram should slide-transition to the right place (like sliding popups that morph into eachother) and the preview rectangle along with the details text should crossfade into the new item.
• When Esc is pressed or the mouse stops outside the preview frame, but not on another grid item, the frame (along with the details and action buttons) should fade away and the actual preview rectangle should downscale into the original grid item.

I think this would be an intuitive UI for previews and the animations and mouse behaviour described here is, in my opinion, intuitive and not overwhelming to use. I am open to suggestions though; anyone feel free to point out flaws in this design. I would especially like to hear the opinions of people more skilled/experienced in UI/UX design than me.

I think the UI you described would be great. Do you think having the content of the dialog would be too much to have in the main page? IMHO it's always better to not split up a settings page if avoidable. The question is whether or not it then actually fits into a page.

I'm not quite sure how much effort it would be to do this for the wallpaper plugins etc in the backend but the stretching over multiple displays should definitely be included into this UI. This could even go as far as making it possible to stretch a wallpaper over some screens but not others:

When you select a screen you get the option to to mark more like in Dolphin by either ctrl+left mouse click or by clicking the "+" on the top right of a display. The two displays would then get marked to be in a group (by color? Or a box that encompasses all marked ones?).
Once you've selected more than one display you can switch between applying the same wallpaper on both or stretching it with one of these buttons that switches between two states (it would be greyed out with only one monitor selected).

As a picture says more than a thousand words I made a quick mockup to illustrate what I mean (both including the display selection into the main page and the multiple selection thing):

Your hover preview concept sounds great! On mobile the preview would then simply open on touch and probably be fullscreen. It's intuitive and useful :)

I'd also be willing to work on this but I'm just beginning to learn the necessary skills as well so it could take some time.

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.

Clicking "Preferences" would bring up a dialog or a different systemsettings page in the main window (with the "<" button taking the user back to the grid) or a popup/overéay over the grid (with an "X" button or the "Preferences" button as a toggle) that contains the screen layout and highlights the chosen ones with a blue frame (substitute blue with the system accent colour) as well as drawing a dim version of the wallpaper over the selected screens. Under it would be the fitting dropdown ("Cropped", "Scaled", "Scaled and cropped", "Zoom", etc.) which would change the rectangle accordingly. The user selects and deselects screens by clicking on them. Screens previously selected for a wallpaper get the new one, but the old one is not rearranged, it stays in place until all screens containing it get changed. The user can drag the rectangle around to adjust which part of the wallpaper is shown. The parts outside the screens are greyed out. There is a link to display preferences and a button to show screen numbers/names. There is a checkbox for applying to all screen layouts containing these screens or just this one (wallpapers are saved by screen config)
Below that would be the activities, with the same select/deselect clicking as the screens. Below that would be the lock and login options which keep the layout described above. Then the "Apply" button and possibly the "Preferences" if it is a toggle.

In a huge window, it could maybe work to have everything in one page, but I doubt that.

Alternatively, we could eliminate the apply button from the main page, and add one instead to the preview overlays in the grid view. That would take you to the "Preferences" screen (that has a "Back" button obviously) to set up how and where you want to apply that wallpaper. Leaving everything there untouched would only apply it to the screen the window is sitting on (NOT the one it was opened from, like current Plasma does), with "Scaled and cropped", centered, and the current activity. Nothing else.
Also the screens could be lasso- or rectangle-selected (drag your mouse around or over (respectively) them while pressing the primary button). The stretch/copy toggle is a nice touch as well, but I am starting to feel that this is getting over-engineered and insanely complex... Mostly my fault though.

Then comes the question of where to store the wallpaper config... Per-wallpaper? Per-screen-configuration? Per-Activity? Globally? This has to be figured out. There could be a new abstract "Wallpaper configuration" object that can be assigned to screen-configurations, activities, the login screen...

On mobile, the wallpaper settings would only contain activity, lockscreen, and fitting method configuration, since handheld devices don't have complex screen configurations. Docked mode (if it will ever exist) will just use the wallpaper for the desktop screen. In case there will be multiple screens support (I highly doubt that), then it could have that complex configuration...

Next question is, should there be a separate dropdown for providers, or could we integrate them into the grid? Then it would be nice to have collapsable categories in the grid, to organize wallpapers and separate dynamic providers like Picture Of The Day.

I think it may be rather important to have a preview visible of how the screens look like with the new wallpaper setup - this would be easily achieved if we showed the screen setup above the grid. I fear that you're completely right however that it's just too much in one page.

The adaptive layout idea sounds good to me. If the user has a high resolution display or the window is big enough it could put everything on one page and if the window does not fit enough rows or of course if the user doesn't even have multiple displays (realistically the majority does not) then it would hide the preview stuff away.

I do think that the ability to also apply the wallpaper on the login and lockscreen should stay easily accessible, although checkboxes might not be the right way to go after all - it's fine for single screen setups but it's not necessarily nice for people will multiple displays.
Perhaps an alternative would be to have additional buttons for that on the hover preview? It's then both easily accessible and neatly hidden away when not actually needed. This would go hand in hand with putting the apply button on the hover preview as well.

A second page for advanced settings is the only solution I can see as well if there's not enough space but It's not a pretty one if the user only has one display. Perhaps it would have its use for showing how the scaling&cropping looks?
A prefererences button on the hover preview could be misleading - it would suggest it shows the preferences for this specific wallpaper. We have to label it better and/or give it a fitting icon. Perhaps simply naming it "options" or something like that would be good enough. The options page should then also have a "Apply" button that closes the page of course.

On mobile, the wallpaper settings would only contain activity, lockscreen, and fitting method configuration, since handheld devices don't have complex screen configurations. Docked mode (if it will ever exist) will just use the wallpaper for the desktop screen. In case there will be multiple screens support (I highly doubt that), then it could have that complex configuration...

There's some problems with using the mobile wallpaper for the desktop screen in docked mode. It works for a tablet (that is most likely already running the desktop experience for plasma though) but on phones the wallpaper is either cropped (where using the same one works) or simply vertical, and that's not applicable on the desktop without cropping or scaling or using big bars on the side. All options are bad. I think the principle behind docked mode would be that you'd then have (at least optionally) the complete desktop experience on the docked monitor(s). We should just use the desktop configuration in docked mode.
If we do use the second page to (optionally) show the scaling and cropping then that second page does make sense on mobile as well. We should IMO make a mode where the user can easily crop as they wish (like it's easily done on most phones) that could optionally also be useful on the desktop.

Inlcuding the providers into the grid instead of using a drop down menu is a interesting idea that could save us some space. IMO they always have to be on top or it would probably get too cluttered. Perhaps we could use tabs there?

Also the visualizer would only be needed when there actually is more than one screen/activity. For the common case of one screen and one activity, it wouldn't need to appear at all.

Wallpaper config is already stored per-"Containment" a "Containment is a thing that each screen and each activity has one of. So that part is already solved. The backend already works fine; this is really just about putting the functionality into a single UI that can be integrated into System Settings.

+1 for finding some way to integrate also applying the wallpaper to the lock screen and login screen in this UI.

please no.
it may sound attractive, but besides the technical diffivulties of writing in the proper place in the plasma config, there is the question of background which monitor of which activity that would require doing a quite complicated spacial ui mapping in systemsettings, where just clicking configure on the actual wallpaper one needs to change requires no mental mapping, it's just there.

We've already done some UI design here for the proposed feature and it doesn't seem like an insurmountable challenge.

I've been collecting user stories from people who want something like this for years, and it solves real problems; see https://bugs.kde.org/show_bug.cgi?id=367666 and its three duplicates. In the end, we can ignore those requests or we can give our users what they're asking for. You know how I feel about listening to our users. :)

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.

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.

Exactly. And now that all KCMs open in System Settings rather than their own window when opened directly from an app menu or search, the wallpaper selector is the odd one out. Many users expect it to be in Settings, but accessible from the desktop via right-click.

Preselecting the right-clicked screen (or the screen the window is sitting on) would also be a really nice feature.

In true KDE fashion, this would not break anyone's workflow or muscle memory, but provide more options and flexibility to the users. Simple by default, powerful when needed.

Ping @PhilipB @abetts

Last one is my latest and favorite, note: I changed Appearance to User Interface, seems more acceptable.

New one, seems more in line with Background change only.

This is one way of solving the bundle of configurations into a more modular set. Add a other settings shortcut button that leads to where the once different bundled options are now.

I think that putting all the background settings in one place makes sense.
I am missing the option to choose a monitor on all of the (otherwise well looking) mockups though. Maybe putting the workspace/activity selection on the left and putting the monitors where the workspaces are in the mockup could work?

My mockups? Yeah, I forgot to color the selected workspace/activity/monitor element.

Because of the confusion that are the current workspaces I've decided to use generic workspace tag but I think Activity is better. If I'm not mistaken, Virtual desktop is very limited and a single monitor case while Activity is more complex and multi monitor friendly.

Yes, virtual desktop is the limited one and activities are more encompassing - neither handles multiple monitors at all though.

What I meant is that in the wallpaper dialog we need to be able to select monitors to apply the wallpaper to. So for example if a user has multiple monitors we could move the activities selection to the left and make it a checklist, and to the right we'd have the monitors to select.
An alternative is what we've been discussing in this thread before: make the user select the wallpaper to apply first, and then show a page to select where it should be applied. I'm no longer entirely sure if that wouldn't be a bit weird though, it kind of reverses the flow of categories of system settings, if that makes any sense.

Check my latest mock up. There's a visual highlight of the selected screen, apply all, activity 1 and 2. Current is apply to all, hence why the highlight selection surrounds all. This can be easily rearranged for mobile mode too.

I honestly don't know what to call each wallpaper area.

I don't mean activities, I mean actual monitors. The view should then look something like in the Display Configuration settings page:

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?

Btw I am sorry that I didn't manage to work on the hover preview UI. The pandemic interfered with everything.

I'm still focusing on the desktop wallpaper hence the lack of log in and lock screen mock ups.

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 tasks to be able to apply and/or sync the wallpaper to the lock and/or login screens is still TBD and does not seem to be unblocked, because the various proposals in this task all relied on there being a "Wallpaper chooser" KCM that the feature could live in.

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.

Which one is the current containment? Is it the one the system settings window appeared on? Is it the one the mouse is on when it appeared? Is it the one it is currently on (it might've been moved to a different one)?

I see this leading to a lot of frustration. It somewhat makes sense for the right-click action to be tied to a specific containment, since the user right-clicked on that specific containment in the first place. But tying System Settings to a specific containment is something no one would expect, and the user can't be expected (or bothered) to understand the concept of containments, so they wouldn't understand why it only changes that one containment.

Also, if there is a wallpaper button in the landing page, users will notice that button, and go 'oh ok, this is where I set up my wallpaper', and click it. But where is Lock/Login screen wallpaper, and where are the other containments? Can you only change that one wallpaper in Plasma?
The other related pages are buried in other random categories and behind right-click menus, instead of being in one place.
At least links to the other wallpaper setting pages (Lock, Login) would be needed either in the per-containment config dialog Wallpaper page, or a totally and fundamentally restructured system for wallpaper selection, since this is a hot mess right now, and the landing page only complicates things. With actual settings being there on the landing page that aren't present elsewhere in System Settings (Wallpaper for instance, or light/dark theme), it is a page people might want to come back to, but they don't find it in search, and the little "home" button isn't discoverable enough IMO.

Besides, if I am not right-clicking and then selecting the desktop config option, I might try searching for it in KWin or in System Settings, only to not find it anywhere. It also doesn't help that there isn't a right-click option in Dolphin (without 3rd party plugins that is) to apply an image as wallpaper (for the containment Dolphin is sitting in)

In Plasma Sprint 2023 we agreed we want to achieve this (https://invent.kde.org/plasma/plasma-desktop/-/issues/89)

zamundaa suggested design is aligned with the direction we were aiming at
https://phabricator.kde.org/file/data/3ib6sdfnmmw7lh54mbhw/PHID-FILE-ieljnhcfvxlf6wkpmqge/mockup.png

First implementation step would be to separate the Config UI from plasmashell process i.e adding a DBus interface.

In T12622#290977, @meven wrote:

In Plasma Sprint 2023 we agreed we want to achieve this (https://invent.kde.org/plasma/plasma-desktop/-/issues/89)

zamundaa suggested design is aligned with the direction we were aiming at
https://phabricator.kde.org/file/data/3ib6sdfnmmw7lh54mbhw/PHID-FILE-ieljnhcfvxlf6wkpmqge/mockup.png

First implementation step would be to separate the Config UI from plasmashell process i.e adding a DBus interface.

Is the selected mockup open for discussion? I think there might be some changes that I want to point out.

Yes. FYI you can leave out the activities bit, at the sprint we agreed that it would be simpler to make the KCM apply to the current activity only

In T12622#291129, @zamundaaa wrote:

Yes. FYI you can leave out the activities bit, at the sprint we agreed that it would be simpler to make the KCM apply to the current activity only

Sounds good

I think my main thing is I want to simplify a bit.

I personally think (if a user's personal opinion counts for anything...) that all of the Settings we have under "Configure Desktop and Wallpaper..." (see https://itsfoss.com/content/images/wordpress/2021/01/2-kde-neon-wallpaper.png - also includes the options on the other sections on the left pane)
should be available in a KCM under system settings.

It's confusing not being able to set it there.
It is it's own weird thing.

It got a lot better by having a "link" on the System Settings's Quick Settings page but... it still feels like "something from another world"...

Still thinking through this, I am asking around to see if we can propose a design that integrates everything properly. Stay tuned.

Backend work started at https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3122

minimal kcm Ui wallpaper MR: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3395