Created attachment 143556 [details]
"Configure Desktop and Wallpaper..." dialog how it should look like (English)

Found from internet at https://technastic.com/configure-kde-plasma-desktop/ the picture, how that dialog should look like, when it works.

Can you please run "plasmashell --replace" in a terminal, reproduce the bug and attach the output here?

Here are command the outputs:
https://pastebin.com/qZ53xJfk - vol.1
https://pastebin.com/rrEaUnes - vol.2

I tried to figure out, what is the exact command to invoke "Configure Desktop and Wallpaper..." dialog window directly from command-line. Then I could run it with LC_ALL=C parameter beforehand to get an English version of appropriate screenshot. I tested systemsettings5, kcmshell5, plasmawindowed commands, tried to combine different modules, commands, etc. Also investigated qdbus org.kde.plasmashell /PlasmaShell options, but did not succeed. I figured out one script for plasmashell to change wallpaper directly (which was useless as easier plasma-apply-wallpaperimage command exist), but to invoke that dialog window directly still not succeeded. I could invoke screenlocker module via systemsettings5 or kcmshell5, which looks very similar, but it is about screen locking and not wallpaper itself. Also tried to investigate KDE, Arch Linux documentation and rest of internet search about that, did not succeed. This all was an eye-opening experience, but still did not get direct command to invoke appropriate dialog window. Does anybody know, whether such direct command exist for that particular dialog window?

I forgot to add, that after running plasmashell --replace, the dialog window works as expected. Also after relogin to KDE, the dialog works as expected. I'm just wondering, why I didn't see warning message about the need to relogin or even reboot. Usually after certain updates such dialog appears. Also adding widgets dialog works now, which was not working, when the issue with mentioned dialog window happened. It seems, that just after update there weren't run that plasmashell --replace command automatically, that caused current issue.

There is no dedicated command for this dialog, it's part of the regular plasmashell process

So you can't reproduce the issue anymore?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

As already mentioned on 2021-11-15, running plasmashell --replace after update solved the issue. Sometimes possibly also kwin_x11 --replace helps in addition. There might be important to ensure these commands are executed in proper order. Sometimes I've needed to rerun plasmashell --replace after the kwin11_x11 --replace.
Just a suggestion: run one or both commands automatically after KDE components upgrade. I would ask feedback from KDE developers about this idea, whether it would be suitable or not. It is just my suggestion as it solved the issue

> run one or both commands automatically after KDE components upgrade
You should always reboot after upgrading, for just this reason. We can't manually restart plasmashell after upgrade because it could be disruptive to you; what if you were in the middle of writing a sticky note? Some changes would get lost.

Using Offline Updates resolves this problem generically. If you're not using Offline Updates, it's up to you to restart running software as needed.

Usually there will be a message if really reboot is required. I kindly ask developers use messaging system in order to ensure proper software installation. In other hands - rebooting after every update sounds not appropriate (like in MS Windows already). Quite often updates are so small, that rebooting is irrelevant. Only developers know, when rebooting is appropriate. Therefore developers should carefully analyze, whether rebooting is necessary or not. The current case, why this report has made, developers forgot to require at least run plasmashell --replace or log off or reboot. Also there could be a message, that either run plasmashell --replace or log off or reboot. Then user will know, what options are required after current updates. Therefore I would not say, that "not a bug" as proper communication was missing between user, who updated software and developers.

To avoid weirdness, you always need to restart an app that was running when it was updated, or when any of the libraries that it uses are updated.

Let's say we added a system to compare the list of updated packages with the list of running software and its library dependencies, and if there was any intersection between the two lists, we sent a notification asking people to reboot the system or those apps after updating.

I think this would not solve the problem because Discover *already* asks you to reboot after updating, and evidently you ignored that notification. :) Discover already told you what you needed to do, but it was up to you to do it. 

Offline Updates solves this entire problem generically by not actually applying any of the pending updated until a reboot is done.

You as a developer possibly know, which component is binded with which app. But most users and admins do not know that, at least not in complete extent. We may know some components, but not all of them. Therefore it is solely on developer's duty to pay enough attention during upgrade, when restarting plasmashell, logging off or even rebooting is necessary. To be honest, it isn't very hard to announce it in a noticeable way, so it won't be missed.

E.g. in EndeavourOS there will be always message on CLI and if in GUI, pop-up says, that rebooting necessary. Such messaging isn't hard but would help avoid lots of troubles unless user, admin understands, that rerunning plasmashell, relogin or reboot is necessary. You may imagine, that people work with Linux and sometimes lots of apps, files are opened. Doing reboot after every small update is not appropriate and makes Linux even worse than MS Windows, that requires reboot after software update, upgrade. In Linux most cases we do not need reboot. Quite often just rerunning plasmashell would help. 

Certainly I need save work beforehand, if it will close any app, which I don't know. Even closing apps and reopening them after rerunning plasmashell would work much faster, than rebooting all the time. You may imagine, that people use also filesystem encryption and perhaps some integration between PAM and KWallet, at least I do. 

So rebooting and re-entering encryption, PAM passwords takes much longer than just saving work and closing apps, rerunning plasmashell and reopening apps. E.g. ProtonMail Bridge is quite reluctant and requires separate approach (pass CLI app for GPG-key) and does not work via KWallet. 

So I need re-enter all these credentials, when rebooting or even relogin. Again - saving work, rerunning plasmashell or GUI effects (kwin_x11) is very often much faster than rebooting. Quite often I don't even need to close all apps but some of them. I try to watch, what apps will be updated and will save work, close only these. 

Besides, I never ignore the message, that says me to do reboot or relogin or whatever else is needed to do. I can confirm, that no message did not appear at the time I made current report and that was main reason for my reporting. As mentioned, rerunning plasmashell solved issue and no reboot was necessary. To be honest, Linux is not Windows, that we need to reboot all the time.

If you just ignore my report and do not announce reboot, even if it is necessary, then you are making KDE usage experience worse. People might even start thinking over Linux in general not good. If the announcement appears on CLI among other output, that quickly flows away, then it is not a proper way to communicate as it is very hard to notice among other text output at CLI the message, that I need to reboot.

As I use EndeavourOS, which updates quite often software, I do also quite often reboots. New kernel, init, other system components diligently tell me to do reboot and I never ignore it. Usually I check the list of packages, that will be updated and usually when I see kernel, init, etc system components in that updates list; I already start closing all apps, virtual machines, etc and saving work if needed to prepare for reboot. 

If I notice e.g. Electron framework will be updated - I close all apps I know, are using that framework. Then I don't need to close all apps and reboot. Just reopening updated apps would be enough

EndeavourOS announces via eos-update-notifier app the GUI pop-up about the need of reboot and it is very well visible. I've used libnotify my own to announce critical messages for users. I've used update scripts via CRON and used such messaging. There are many ways to show such pop-up messages, that is well seen on screen.

We *do* announce that a reboot is needed when you're not using Offline Updates. We do it in two places once the update is completed:

1. The app window itself changes to a big message that says "reboot now" and has a button you can click on to reboot
2. A system notification is shown that says the same thing, and it also has a button

We could make the system notification persistent so that it has to be explicitly closed. Right now it times out after the normal system timeout duration (5 seconds by default). However if we do this we will surely get bug reports from the people who are annoyed by notifications. Everything is a trade-off.

If the update in question did not actually show the "you need to update" message, then I think it may be a bug in your distro's packaging. Distros mark packages as "this will require a reboot when updated" or not.

Or you can just use offline updates which leave your system untouched and safe until you choose to reboot at your leisure. I'm not sure it makes sense to significantly change the Online Update use case to fix this issue when Offline Updates have already fixed it.