This is a recent install of Leap 15.1. I use Plasma.
I configured fonts and themes both for a non-root user and root. Applications’ windows, fonts and icons look good.
But when I do
su -
, become superuser in a terminal, and then start an application as root, then the window of that application looks bad: fonts are too small (in particular, fonts in popup boxes and menus), and the theme is an unusual one, one that I do not use.
This applies to all applications started, for example, kate, firefox, konsole, yast2.
I have forced the correct DPI for root and non-root user.
I created a fresh user, and observed the same.
Earlier, I could resolve a similar issue by setting up desired values in GTK settings and by forcing DPI, but with 15.1 this does not work.
I remember having a similar problem with sudo/kdesu etc, and I could alleviate it by setting my theme and font size in /root/.config/gtk-3.0/settings.ini by copying over my user settings to it with a text editor.
Here’s my /root/.config/gtk-3.0/settings.ini:
I do not quite understand all the things you are describing.
Normaly I start YaST from the end-users GUI (KDE) session by clicking on the icon, etc. All looks normal.
Sometimes (e.g. when I want to see it in another language), I start it from a "Terminlal - superuser mode) which starts Konsole with su -) with e.g. LANG=C yast2 and I get the same “normal” windows.
I know some use kdesu kate for editing root managed files, but I use vi from the su - terminal, thus I have no experience here.
I of course never start FF as root, that being one of the more stupid trials to compromise my system.
I never tried to set any KDE configuration values for root, because root never uses a GUI. As far as I understand it, The YaST windows are simply organised by the configurations of the GUI session (of the end-user).
Could be that I do things in a complete different way then you, but I can not reproduce your problem here.
# HOME=/root systemsettings5[/HOME]
and then configure font settings for the root user.
Note: I have not tried this. And I am assuming, perhaps wrongly, that this is for KDE.
I have generally found across all OS (not just Linux) that configuring dpi produces unexpected and uneven results and never recommend that approach.
Instead,
I always recommend configuring themes and screen resolution using system and graphic environment tools… and have never had a reported program thereafter.
Recommend returning all your dpi settings to default (there is often a “default” button to help you) and then use the other tools I described to modify appearance.
There is not one single default. Xorg defaults to 96, but it can be overridden by xorg.conf*, xrandr and/or a startup switch.
GUI tools to force DPI mostly use xrdb’s Xft.dpi, the knob Gnome provides for “scaling”. Xrdb’s default is null, unless you are using gtk 3.17 or newer on any distro except current and recent openSUSE. GTK3’s post-3.16 default is to replace null with 96 if nothing has set it non-null. openSUSE undid this misfeature in bug 1022830 after pleas to do so fell on deaf ears. GTK and QT apps take their direction from Xft.dpi if it exists. Among other apps, some do, some don’t, among the latter, Xterm, Xmessage and their x11-tools kin. Last I checked many moons ago, WINE was epoxied to 96, and *Office nearly as bad, forcing all UI and content to be set either entirely from within, or a combination of within and an rpm theme.
Over a dozen years ago, X would calculate correct physical DPI from EDID size and resolution. It still could if it wasn’t disabled in order to match Windows’ and Mac broken behavior forcing 96 regardless of actual physical. That it still could is evidenced by the fact that manually feeding DisplaySize to it in xorg.conf* results in accurate physical, or any arbitrary, DPI.
How it works in Wayland I have no idea. I have yet to find a reason to try it, given its heritage, or developmental state.
I work as non-root user. Then, in the middle of that work, a need arises to do some work as root, for example, to do some manipulations with files and folders that need root access.
I don’t logout. Instead, I start dolphin as root after “su -”. The dolphin comes onto screen with very small fonts and bad icons.
To reproduce:
1) Use KDE.
2) Login as root and adjust fonts and themes, including for GTK applications. Achieve nice looks. This succeeds.
3) Logout or reboot.
4) Login as non-root and do the same. This also succeeds.
5) Don't logout. Open a terminal and there become root via su -
6) Start a popular graphical application, for example, kate, dolphin, yast2.
7) Check whether the fonts and icons look good and similar to the configured ones.
I have added DisplaySize in xorg.conf, it had no effect.
The problem seems to be related to a missing or wrong theme configuration, since not only the fonts are small, but also the theme (buttons, colors, icons) that comes up is not the one that have ever selected.
The small fonts appear both in KDE and GTK applications.
In these screenshots, only Konsole was opened as normal user. Everything else was opened from the middle Konsole tab, where the first command was su -.
The primary difference, with or without ~/.Xresources, is visible just right of image center in the lower left corner of the Xterm window. Mostly there is little to no difference anywhere except the fonts in the Xterm. Without, some bitmap font is used. With, the desktop’s monospace font specified, Droid Sans Mono, is utilized, same as in Konsole, except size 10 in Konsole and size 11 in Xterm.
I don’t ever use a GUI file manager, so Dolphin isn’t even installed. Firefox is missing in part because it manifests no apparent difference.
xterm*faceName: Droid Sans Mono:antialias=true
xterm*faceSize: 11
xterm*vt100.geometry: 120x43
Try this to see what difference it makes. I just spent at least 90 minutes getting a couple of screenshots to show differences with and without ~/.Xresources here, but susepaste.org is not accepting my images either via CLI or the web, without explanation as to why.
I just dug into my command history and into my (unfortunately far too sparse) setup notes, and I discovered why I repeatedly had problems similar to yours, and how I probably solved it. It’s not pretty. I ended up editing at least the following files:
Obviously no amount of mouse-based GUI configuration would ever cause any change in those files — normally, we should never ever need to hack those because they could get overwritten by any Gnome/GTK update. But in the special case of making sudo’ed programs look like any other program, I found no other way but modify those files under /usr/share/ … because apparently a kdesu’ed Dolphin or a gksu’ed YaST seem to get their own »sudo-local« X environment (wholly independent from configs made in either /root or /home/non-root-user). Only after editing those rc files and css files to my liking did my YaST2 then have the same look&feel, no matter whether I …
started YaST via non-root-user GUI and have kdesu ask for the root password; or…
did a »sudo -i«, followed by »cp /home/non-root-user/.Xauthority /root/; export DISPLAY=:0« and finally started yast2 from that root shell while using my non-root X session; or…
logged in via display manager as root into IceWM or twm and then started YaST; or…
started YaST as non-root-user without any su/kdesu/gksudo (just for comparision’s sake; can’t do much with an unprivileged YaST).
Ovbiously, if you go the route of experimenting with changes under /usr/share/themes, make a quick backup of those files for the record and for reference; and please do a better job than I did at documenting the steps you’re attempting and reverting. Happy hacking!
I’m using a “.Xresources” file for my normal login user. And it works.
I only set the font size
xterm*font:6x13
And that works for a root xterm started in my session.
However, it does not work for an xterm started in a Gnome Wayland session in Tumbleweed. It still works for a Plasma Wayland session in Tumbleweed. And it works in Leap 15.1 for Gnome Wayland.