systemsettings is behaving differently when run as root and when run as user:
When run as user:
there’s a button called “Configure Gnome/GTK Application Style” (Appearance > Application Style)
no preview is shown when trying to install new desktop themes
globally installed themes (as root) are not in the list to choose from
When run as root:
the button called “Configure Gnome/GTK Application Style” is missing
preview when installing new desktop themes does work
What could be the cause of these strange behaviour? I’d guess it’s some permission issue, I need to add my user to another group. But that still wouldn’t explain why the “Configure Gnome/GTK Application Style” button is missing for root.
Maybe taking a step back…why are you looking to run System Settings as root? Appearance settings will be user-specific, so if you change the settings for the root user, that would only apply to graphical apps that “root” runs - which should be practically nothing, right?
Have you tried any of the suggestions from the top Google hits? This one seems particularly relevant and contains both the cautions and suggestions:
Hmm…maybe my thinking is antiquated on this, but I would think that you’d want to have some sort of alerting, “in-your-face” indicator to let you know that you’re running a GUI app as root, given the different level of power root has and the file ownership challenges that could be introduced? But to be fair, I haven’t really spent much time at all on distros where running GUI apps as root is a necessary part of routine maintenance.
My problem is not about using the same theme as user and as root. I wanted to install some desktop themes, and I noticed that the normal user does not see any previews. Then I remembered reading something about this, and I also noticed the missing button. I think both problems are related.
given the different level of power root has and the file ownership challenges that could be introduced?
Well, sometimes a regular user operation can be much more devastating than a root operation, because sensible data are always stored in HOME folder and not in any system folder, and if a user has access to root password then he is the only responsible for his actions.
I used many apps as root for years and no problem occurred.
And concerning theming, it can be annoying if you have a nice dark Breeze theme applied to all your opened apps then suddenly a white app appears on the screen, your eyes will surely hurt after using it for long time.
I wished if Plasma settings could apply the same dark Breeze used by regular user to root but with additional red titlebar and/or red frame or shadow to make them distinct without hurting user eyes.
On a fresh load of Plasma on Tumbleweed, I knew I would be using Breeze Dark. I set my colors to look like the Dolphin on the left. I copied the ~/.config and ~/.local folders over to /root and then set my colors to the Dolphin on the right. Now, I have both looking very different, so as not to make changes by mistake. If I am in Dolphin as root, I know it. and there are context menus that are unreadable if the root still runs as Breeze. The text is invisible.
If you like that ability, grab Dolphin-SU from my GitHub. The only difference between the two sides is the Accent Color. Yes, openSUSE gives us a Root Dolphin, but you can use the .desktop file anywhere.
I have also used the Dolphin extention to add Open As Root to the right-click menu, but you still need to set the colors because of the invisible text names on the files when looking at white text on white backgrounds.
I think there’s some misunderstanding here. Maybe my description of my problem wasn’t clearly worded, so I’ll try in other words:
My aim is not to set the same desktop theme for user and for root!
I wanted to install a new desktop theme (as user), and the preview window did and does not show any previews. I remember reading about this being a very old bug, that apparently has not been fixed yet:
Systemsettings > Global Appearance > Get New Global Design
By the way: previews are also missing when trying to install new plasma themes, new icon sets, or anything that systemsettings is supposed to show previews.
So I called sudo -i systemsettingsjust to see the previews, because root does see previews. I can then choose the design I want by name as user and install it.
While root’s systemsettings window was opened, I noticed that the button marked “Configure Gnome/GTK Application Style” is not there, while it is there in the user’s systemsettings window: Systemsettings > Appearance > Application Style
That was wondering me.
For the second part of my original question:
While root’s systemsettings windows was opened, I thought I could as well install themes that I like by using root’s systemsettings. I thought that themes installed by root would be available to all users on that system as well. Apparently, this is not the case: it seems that desktop designs can not be installed globally by root, if they don’t come as part of the system’s package management. Any design installed via KDE systemsettings is available only to the person who installs it, be it root or a user.
Thank you for clarifying. I will also do some clarifying: running a GUI app as root is never an appropriate troubleshooting tool or workaround for some issue you found. Doing so is highly likely to cause other subtle problems that will be hard to diagnose later.
KDE provides no support for running apps as root that were not designed or intended to run as root, and I recommend discontinuing the practice.
If you aren’t seeing GTK theme previews when running System Settings as your normal user, that is the problem we should be trying to help you with, not a problem related to the dangerous workaround you found.
That ability already exists via kio-admin. Install it, right-click on the background in Dolphin > open as Administrator and then go hog-wild.
I don’t fully understand myself why it had to be done like this rather than showing password prompts when you try to move or copy root-owned files normally, but based on the multiple years of effort behind it that ended up amounting to nothing, I gather it is a surprisingly hard problem to solve in a correct and secure manner. @sitter might be able to provide more detail about this.
I also wonder how common is actually is to need to move or copy root-owned files. In my personal life and professional career I have only ever had to do this as a part of some complicated manual installation process for internal business-specific software, or some super custom “you’re on your own here” type of project. In both cases, a person undertaking such a task should absolutely be a technical expert who’s familiar enough with the command line to be able to do it that way. If they aren’t, also in my professional experience (in the help desk part of the tech industry) it’s highly likely they’ll blow up their system by accident.
I am asking about the difference in the copy action. BUT, both would be good.
Granted, opening Dolphin as root is not a daily occurrence. It’s pretty rare, unless I change some configs and need to back them up to keep my backup fresh. As far as my /home folder, I just do that with grsync.
I only copy root owned files to locations where they will still be root owned. I also realize that mistakes can be made, but they can be made at the command line as well. This is why my color scheme for both Dophins is different. As shown in the post above.
A copy is not a copy in either. The primary difference is that dolphin just a lot more complicated piece of software with ever so many features that are impacted by a simple copy.
Off the top of my head: a copy is comprised of a bunch of readdir calls (when it is a directory), a bunch of stat calls, a bunch of read calls, a bunch of write calls, a bunch of chmod calls (read/write is possibly condensed depending on the specific implementation code and filesystem). Dolphin on top of that is concerned with thumbnail rendering, disk space availability tracking, xattrs, acls, metadata reading for the sidebar thingy. I’m probably even forgetting some stuff.
That is the primary reason why the problem of elevating a single user facing actions is so tricky. A single copy should only require a single authentication but that means one would somehow have to transparently transfer a bundle of all subactions into elevated scope without losing any context. And then you have subactions that depend on evaluation of another subaction (e.g. a directory copy is different from a file copy). That is even ignoring the fact that in order for you to copy something you first need to be able to browse it (e.g. consider a file that is root:root 0600).
I think it’s indeed safer to manipulate root files in a TUI file manager, or a standalone GUI file manager not bundled in a DE. Not only in the sense of fewer vulnerabilities, but also that a copy is just a copy, not something involving KIO/GVFS and XDG Desktop Portal and a copy operation would go through dozens of functions written by different people in different projects.