GUI scaling

[Duncan]

Bernd Nachtigall posted on Wed, 24 Oct 2018 07:44:51 +0200 as excerpted:

> Hi,
> 
> in KDE you can scale the whole display. (use systemsettings / Display
> and Monitor / Display / Display scaling)
> 
> I try this and set scaling to 1.2. I reboot and found that this not
> usable for me. I set this value back to 1.0, reboot, but the scaling is
> not reverted :-\ (Now may monitor is to small ;-)
> 
> How is the way to get the scaling back to normal? Is there a way without
> the use of the systemsettings menu?
> 
> Bernd
> 
> BTW: the menu names are translated from german to english. So maybe they
> are not accurate.

OK, I have a "plasma-lite" installation here, without some components I 
find more trouble than they are worth, and in plasma systemsettings, 
display and monitor, I don't have the display applet, which I believe is 
part of kscreen, which I don't have installed (because using it would 
break the existing X configuration and I'd have trouble getting things 
back they way I wanted, sound familiar? =:^( ), but...

Here's a generic answer that applies to pretty much anything kde/plasma 
related, that I hope will help:

In general, yes, there's a way to reset everything, you just have to 
figure out which config file to edit or delete to do it. =:^\  At least 
all kde/plasma settings are stored in plain-text files and thus can 
almost always be easily edited, once you figure out which file to edit! 
=:^)


There are two ways to figure out what to edit:

The bisect method, brute force and requires patience, but not too much 
technical knowledge:

First, confirm that the setting for a clean config is working.  Either 
create a new user temporarily and try it there, or move all your normal 
user settings elsewhere temporarily, so you start with a clean config, 
and ensure that works.

If a clean user config doesn't work, the problem is at the system level, 
perhaps a recent update from your distro.

Assuming you've confirmed it's a setting in your user config, you then 
"bisect" the problem down in steps, testing roughly half the potential 
setting space by backing up and then removing (with the thing under test, 
plasma in this case, shut down) the other half, then based on whether 
it's in the remaining half or the removed half, testing half of the bad 
half, bisecting the problem space roughly in half at each step until 
you've isolated the specific directory, then the specific file, with the 
problem in it.

Once you reach the specific file, you can either just delete it and start 
over with fresh settings for everything it controlled, or switch from a 
file manager to a text editor for testing, and dive down into the 
configuration section and then individual line.

>From experience with plasma, I can tell you that most settings are 
under .config (well, the XDG_CONFIG_HOME environmental var, which is 
normally set to $HOME/.config), in your home dir.  So at the first bisect 
step after confirming it's a user setting, not system, I'd back up 
~/.config and remove it (with kde/plasma shut down, of course), then 
start plasma to test if the setting is reset or not.  If so, try with 
only half the files/dirs in ~/.config, otherwise, try ~/.local/share (or 
$XDG_DATA_HOME) instead, as that's the other common location.

The bisect method works for all sorts of stuff and is great because it 
doesn't require a lot of specific technical knowledge to do it.  In fact, 
it's so effective and popular there's a git bisect command to help people 
nail down the specific patch/commit that introduced a bug, and I use it 
routinely for that purpose to nail down new bugs in both the Linux kernel 
and the live-git kde/plasma I run, so as to more effectively report them 
because I can report exactly which commit introduced them, even if I'm 
not a dev.


The strace/grep method, a bit more technical but less repetitive:

The strace/grep method uses strace -eopen or similar to trace the files 
opened by the process you're trying to find the config file for.  But any 
modern X-based process will open hundreds or thousands of files as it 
starts, libs, system config, icons, fonts, etc, in addition to the config 
file you're looking for, so to filter out some of the noise, pipe the 
strace output to grep -v to kill what you do NOT want to see.  Of course 
run in a terminal/konsole window.

For a kcm (kcontrol module, aka systemsettings module, as it was called 
kcontrol before), the easiest way is to figure out which module you're 
looking at and invoke it directly, using kcmshell5 <module>.  You get a 
list of the modules with kcmshell5 --list (again, run in a konsole 
window).  Then from the list, choose a kcm that looks like it might be 
the one you need, and run it.  Once you have the kcm you want, then strace 
it.  That way, you avoid all the strace output from just opening 
systemsettings and browsing to the kcm you want, by opening it directly.

I did say this method's a bit technical, so I'll assume if you are going 
to use it you already have some familiarity with strace and grep so I 
don't have to give you the specifics, but I do use this myself from time 
to time, and it does work. =:^)


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman