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:
> https://community.kde.org/Solid/Projects/
ScreenManagement#Debugging_Information
>
> It starts with this instruction:
>
> Create a script with the following content:
>
> #!/bin/sh
> export KSCREEN_LOGGING=1
> 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
environment.)
--
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
