I think then you would have to type in your password every time you change a setting.

Would you really? There couldn't be a service running with the right permissions that automatically synchronizes settings on logout/user switch/shutdown/when a change is detected? It seems like it should be possible, but I don't know what the security implications would be.

I think then you would have to type in your password every time you change a setting.

Would you really? There couldn't be a service running with the right permissions that automatically synchronizes settings on logout/user switch/shutdown/when a change is detected? It seems like it should be possible, but I don't know what the security implications would be.

It's copying to sddm owned directories so it does need root permissions... something would have to be worked out, not sure what the possibilities are though. Also this would have to be enabled by default solely for single user systems, otherwise you run the risk of the login screen always changing appearance based on the user that was last logged in.

I think then you would have to type in your password every time you change a setting.

Would you really? There couldn't be a service running with the right permissions that automatically synchronizes settings on logout/user switch/shutdown/when a change is detected? It seems like it should be possible, but I don't know what the security implications would be.

It's copying to sddm owned directories so it does need root permissions... something would have to be worked out, not sure what the possibilities are though. Also this would have to be enabled by default solely for single user systems, otherwise you run the risk of the login screen always changing appearance based on the user that was last logged in.

I think it could be done with a systemd service, but I don't think we want to start directly depending on systemd. Maybe we could just keep this patch like it is and write a separate systemd service file for people to download from https://invent.kde.org/kde/kde-vdg-extras until we have a more user friendly solution.

Overall this is very nice! I have some inline comments, and some design comments:

You need to handle failure conditions for the remove, mkpath, copy, chown etc. operations. Thede functions all return false if they fail, so you can find out easily enough. There's nothing worse than an unhandled error, because then the operation will just fail silently, leaving the user confused. Even showing an ugly error dialog box would probably be better than nothing, though a KMessageWidget would be much nicer.

This should be considered a framework for optionally having the sync operation done automatically when selecting a new theme/icon set/font/etc. The feature is nice, but not very discoverable, and the better UX is to have new settings synced to SDDM automatically for the case where there's only one admin user account on the box.

We need to come up with a way for user-installed content from GHNS etc. to get synced. If detecting when it's installed in a non-system location is unfeasible, we should consider installing new content to a system location rather than in the user's homedir, either optionally of even by default.

As for point 3, I've looked it additionally and it does complicate things but might be doable. The question is how to interact with the user. We could copy everything to a global directory and then remove it from the user directory (to avoid duplicates in kcms). What sucks is that users could no longer easily remove these theme files via kcms. So what if we the remove button worked with globally installed? Currently I'm not sure of the repercussions for stuff installed via package manager.

As for point 3, I've looked it additionally and it does complicate things but might be doable. The question is how to interact with the user. We could copy everything to a global directory and then remove it from the user directory (to avoid duplicates in kcms). What sucks is that users could no longer easily remove these theme files via kcms.

Definitely something to ask @leinir about. The GHNS dialog would have to be involved in any event, either to (optionally or by default) install things globally, to know how to remove themes that are globally installed, and to de-duplicate themes that are installed both locally and globally.

In general we do need an additional message box which says sync successful or failed. And then in the case of failure it should state what failed.

But as far as I can tell the operations won't fail. They're all conditional on values being existent or not and if things aren't in order they won't get carried out.

Famous last words. :) You never know what situations users will get themselves into. Maybe they discover the feature while testing with a live CD where the root filesystem isn't writable, for example.

If that's the case then the whole KCM needs to be disabled because any change made within it entails writing to root. This would be relevant to the function though when abstracted and used throughout KCMs. Another thing that crosses my mind in regards to failing is BSD (due to different generic paths), but I have no idea if they even use SDDM.

Well whatever the case, I need to have a look at how to add all this fail/success info.

If that's the case then the whole KCM needs to be disabled because any change made within it entails writing to root. This would be relevant to the function though when abstracted and used throughout KCMs. Another thing that crosses my mind in regards to failing is BSD (due to different generic paths), but I have no idea if they even use SDDM.

Hmm, that's true, so this is a pre-existing issue then.

Okay, let's get this in and focus on polishing it in subsequent revisions!

"Synchronization failed." is a pretty frustrating error message. The user will wonder, "How did it fail? What happened? How can I fix it?" etc. Since we have the error text, let's show it in the message box, since it could provide some clues.