how to debug kscreen?

Duncan 1i5t5.duncan at
Tue Jul 17 20:43:25 BST 2018

Bug Reporter posted on Mon, 16 Jul 2018 14:26:48 -0400 as excerpted:

> When filing bugs related to kscreen, we are told to add information
> according to this guide:
> It starts with this instruction:
> Create a script with the following content:
> #!/bin/sh
> export QT_MESSAGE_PATTERN="[%{time hh::mm:s.zzz}] 
 %{function}: %{message}"
> It also includes editing ~/.config/QtProject/qtlogging.ini
> So far, those steps are clear to me. However, later that guide also
> suggests:
> If your bug is related to how KScreen reacts to certain events (for
> example you plug your monitor and nothing happens), execute the
> following in a terminal and reproduce the bug:
> export QT_MESSAGE_PATTERN="[%{time hh::mm:s.zzz}] 
 %{function}: %{message}"
> kquitapp kded
> kded5
> That is where my confusion starts. The export statement is exactly the
> same as the one already established and which I expect to now run every
> time I login to plasma. If I have created the suggested script and then
> logged into plasma, will it still be necessary to do the above manual
> step? If so, why?
> I do not expect my regular non-technical users to be able to do that
> step. I need to enable debugging in a way that does not require their
> manual intervention in a terminal.

Without actually looking at the URL, I believe I understand what they're 
trying to do and why:

* As kquitapp(5) --help says in different words, kquitapp(5) is simply 
the kde way of asking a dbus-enabled app to quit via its dbus interface.

(AFAIK it's actually kquitapp5 now.  That bit obviously hasn't been 
updated for kde-frameworks-5, and if you have a plain kquitapp around, 
it's either the kde4 version, or your distro is doing some renaming.  I'd 
check the kded in the line too, as I suspect it needs to be kded5, making 
it kquitapp5 kded5, but I'm less sure about that -- maybe the dbus 
interface name is still kded (no 5) and it's that, not the executable 
filename, that it's using.  You can try both and see what actually 
terminates the kded5 process on your system.)

* kded(5) is the "kde daemon", aka kde with a d suffix to denote the 
daemon aspect.  Daemons are what background system services are called on 
Unix-like OSs, and kded is the background kde system service, one of the 
kde frameworks in 5, providing various individual app-services to other 
kde-frameworks-based apps.

* With that in mind and the immediate reinvocation of kded5 on the next 
line, the obvious intent is to quit and restart kded5 with the newly 
exported environment var value.

The concern is obviously that kded5 didn't get the setting in the 
previous script, either because the earlier script is specific to kscreen 
(perhaps it launches kscreen later in the script) and doesn't change the 
larger environment that other kde-based apps inherit, or because kded 
/is/ a background framework service, starting early in the kde 
initialization, likely before the script they had you create is run (if 
the instructions have you set it to run at kde/plasma startup).

* So if your concern is keeping users from having to mess with the 
terminal, the obvious solution is to set/export the desired variable 
appropriately in the global system environment setup, before X/plasma 
starts.  Then you shouldn't have to set it in either of the places 
recommended above, as it's already set, and you won't have to restart kded 
either, as it'll already have the desired environment set when it starts 
normally. =:^)

(Of course be aware that it might get unset or reset to something else 
somewhere along the line.  Probably won't be an issue, but if you're not 
getting the debugging info you expect from setting it globally, you might 
verify that the app in question actually has the variable set as 
expected.  There's various ways to check a running app's environment, but 
the one I find simplest here as I already have the tool installed for 
other reasons, is htop, a much more powerful and thus useful version of 
top, using htop's "e" hotkey to list the selected application's 

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

More information about the kde mailing list