Bug 429435

I've just tried setting back Breeze as widget style and problem persists, with no visual change.

I've now tried checking my sister's PC which also is a Fedora 33 install with up to date plasma, it's not affected. I've checked both pcs' logs and saw nothing different while using krunner.

I've then tried:

sudo dnf reinstall "*kde*" "*kf*" "*plasma*"
mv .cache/ cacheold
mv .config/kdeglobals plasma_backup/
mv .kde/ plasma_backup/

With no luck. Here I've stopped since I made a lot of personalization to Plasma during years and don't want to loose all of that. Nontheless this is soon starting to get frustrating as basically I cannot make use of krunner (a part from eye-candiness, some UI elements are rendered black on black or white on white)

Can you please run `kquitapp5 krunner` and then `krunner` in a terminal and check if it makes any difference.

And does it work when you use the "Search" plasmoid?

Also do you use wayland or X?

(In reply to Alexander Lohnau from comment #3)
> Can you please run `kquitapp5 krunner` and then `krunner` in a terminal and
> check if it makes any difference.
> 
> And does it work when you use the "Search" plasmoid?
> 
> Also do you use wayland or X?

I'm using X. I have some stuff for you here.

1) starting krunner from terminal after kquitapp5 leads to some app behaving correctly. I'm not sure about the logic of this but it's reproducible:
- ksysguard, ksystemlog, system settings, okular, kwrite, dolphin, elisa, kdevelop behave correctly
- dolphin, okular, kwrite, kdevelop misbehave if a document (or folder) is opened by using krunner. I'm pretty sure even the others app would do the same if used to open something.

Also, this is what I get in konsole (first line does not appear in system log):

[dave997@localhost ~]$ krunner 
Cyclic dependency detected between "file:///usr/lib64/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml" and "file:///usr/lib64/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ScrollViewStyle.qml:47:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ScrollViewStyle.qml:47:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/share/plasma/look-and-feel/org.fedoraproject.fedora.desktop/contents/runcommand/RunCommand.qml:41:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
kf.plasma.core: findInCache with a lastModified timestamp of 0 is deprecated
kf.plasma.core: findInCache with a lastModified timestamp of 0 is deprecated
kf.plasma.core: findInCache with a lastModified timestamp of 0 is deprecated
kf.plasma.core: findInCache with a lastModified timestamp of 0 is deprecated
kf.runner: KRunner plugin "ktp_contacts" still uses a .desktop file ("plasma-runner-ktp-contact.desktop"). Please port it to JSON metadata.
QObject::connect: Cannot queue arguments of type 'Consumer::ServiceStatus'
(Make sure 'Consumer::ServiceStatus' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'Consumer::ServiceStatus'
(Make sure 'Consumer::ServiceStatus' is registered using qRegisterMetaType().)
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/org/kde/plasma/components/Highlight.qml:34:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:196:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
.... goes on like this. Sorry for word wrapping, I can't find how disable it.

2) using the search plasmoid produces identical results as running krunner from terminal. Except it also made my whole desktop crash, and in the possibility it's something related I'm posting the trace as a new attachment.

Created attachment 133528 [details]
search plasmoid makes plasma crash - trace

Okay, the search plasmoid crashing is not intended^^

But I have the suspicion that this is because in the D-Bus activation the ENVs are not all contained.

I also suspect that this is the cause for wayland issues on high DPI.

@davidre Could you please have a look :)

(In reply to Alexander Lohnau from comment #6)
> Okay, the search plasmoid crashing is not intended^^
> 
> But I have the suspicion that this is because in the D-Bus activation the
> ENVs are not all contained.
> 
> I also suspect that this is the cause for wayland issues on high DPI.
> 
> @davidre Could you please have a look :)

Ok!
Everybody I'm here if you need tests or whatever.

(In reply to David from comment #7)
> (In reply to Alexander Lohnau from comment #6)
> > Okay, the search plasmoid crashing is not intended^^
> > 
> > But I have the suspicion that this is because in the D-Bus activation the
> > ENVs are not all contained.
> > 
> > I also suspect that this is the cause for wayland issues on high DPI.
> > 
> > @davidre Could you please have a look :)
> 
> Ok!
> Everybody I'm here if you need tests or whatever.

Are you able to test on a fresh user account please?

(In reply to Justin Zobel from comment #8)
> (In reply to David from comment #7)
> > (In reply to Alexander Lohnau from comment #6)
> > > Okay, the search plasmoid crashing is not intended^^
> > > 
> > > But I have the suspicion that this is because in the D-Bus activation the
> > > ENVs are not all contained.
> > > 
> > > I also suspect that this is the cause for wayland issues on high DPI.
> > > 
> > > @davidre Could you please have a look :)
> > 
> > Ok!
> > Everybody I'm here if you need tests or whatever.
> 
> Are you able to test on a fresh user account please?

I've just done the testing. I repeated the same steps as did with my account and observed that:

1) out of the box, krunner misbehaves exactly as seen on my account;
2) running krunner from konsole after kquitapp5 now restores normal behavior completely, even opening files;
3) search plasmoid still sticks to the same behavior of terminal-run krunner

I think point 2 is the most interesting here. I'm also posting krunner output in a moment.

Created attachment 133553 [details]
krunner executed from terminal, fresh account

Extra test information provided.

Just want to add that in addition to this happening with Krunner I have also noticed that the prompt to unlock the keyring exhibits the same behavior (I have auto log in configured, it prompts me to unlock the keyring afterwards).

Can you check if the krunner process is already runnign when you log in?

(In reply to David Redondo from comment #13)
> Can you check if the krunner process is already runnign when you log in?

That's a no, krunner is not started until I use it. I'm posting screens.

Created attachment 133581 [details]
Krunner startup

See I've done my best to reduce interaction with plasma by remaining inside tty2 and krunner was not started even after Plasma loaded completely.
The last screen was instead taken after I'd typed some words in the desktop.

So when krunner is started the first time after logging in via shortcut it shows the broken behavior? 

If I read this thread correctly, killing krunner and starting it from a terminal fixes it? 

What happens if after logging in krunner is started from terminal?

What happens if after killing krunner, it is started via shortcut again?

(In reply to David Redondo from comment #16)
> 1) So when krunner is started the first time after logging in via shortcut it
> shows the broken behavior? 
> 
> 2) If I read this thread correctly, killing krunner and starting it from a
> terminal fixes it? 
> 
> 3) What happens if after logging in krunner is started from terminal?
> 
> 4) What happens if after killing krunner, it is started via shortcut again?

I've just turned your reply in a numbered list for clarity :)

1) Yes
2)It's a bit complicated. Yes on a fresh user account, no on my account where opening documents still shows broken behaviour.
3) I'm testing in a moment
4) Broken behaviour is resumed

3) Same behaviour as when killing it and executing it from terminal

For now then I would assume something is wrong with the starting from shortcut
Since 1 and 4 are broken but 2 and 3 seem to work

(In reply to David Redondo from comment #19)
> For now then I would assume something is wrong with the starting from
> shortcut
> Since 1 and 4 are broken but 2 and 3 seem to work

I do agree with that. But also, don't forget (case 3) that for me typing in krunner:

okular
some_document.pdf

is different. The first one shows normal behavior, the last does not. 
It's the same for every app which handles files.

(In reply to David from comment #20)
> (In reply to David Redondo from comment #19)
> > For now then I would assume something is wrong with the starting from
> > shortcut
> > Since 1 and 4 are broken but 2 and 3 seem to work
> 
> I do agree with that. But also, don't forget (case 3) that for me typing in
> krunner:
> 
> okular
> some_document.pdf
> 
> is different. The first one shows normal behavior, the last does not. 
> It's the same for every app which handles files.

sorry, I meant cases 2 and 3

*** Bug 429512 has been marked as a duplicate of this bug. ***

(In reply to David Redondo from comment #13)
> Can you check if the krunner process is already runnign when you log in?

Krunner is not running when i log in, however i still get the not themed pop-up asking me for a password to unlock a keyring.

Hi, 

Came here to say that i face the exact same issue. Apps like KMail, Spectacle that i usually launch from KRunner look "odd" with a very basic, old look. 

Tested the workaround mentioned here to launch those apps through the start menu or through a global shortcut and the issue no longer occurs. 

Fedora 33. Plasma got updated yesterday through DNF to 5.20.3. 
KDE Frameworks 5.75.0. Qt 5.15.1

I can confirm issue is still present for me as well.

Created attachment 133802 [details]
Config dialog appearance difference from apps started from KRunner and from start menu or global shortcut

Example 1 : Config menu appearance difference from an app started from KRunner and from start menu or global shortcut

Created attachment 133803 [details]
Config dialog from Spectacle when started from KRunner

Config dialog from Spectacle (screenshot app) when started from KRunner. 
The appearance is not part of any selectable theme so i'm not sure where the basic look is coming from.

Added some screenshots. 

I have another desktop on Fedora 33 also but that is still on 5.19.5 and the issue does not occur there. Will not update plasma there in the meantime. 

Let me know if some logs or otherwise are necessary, or comparison logging between my laptop on 5.20.3 and desktop on 5.19.5. 

If it helps, i don't generally do a fresh install when ugrading between fedora releases, so both the desktop and laptop installs date back to many fedora releases back.

Have an issue which I believe is related to this one... when I hit "Alt+F2" to bring up KRunner, it no longer finds items in my PATH.  Finds them in the system path, but the "export PATH=$PATH:..." statement that I have in my own "~/.config/plasma-workspace/env/path.sh" file is ignored.

I suspect that the underlying cause is the same as what causes the issue described here, in that various ENV vars are no longer available to KRunner when it is executed, which would normally have been available to it.

Is KRunner now being started by some other process, and thus is no longer a child of "plasmashell" or "startkde" (or whatever script replaced "startkde")?

(In reply to graham from comment #29)
> Have an issue which I believe is related to this one... when I hit "Alt+F2"
> to bring up KRunner, it no longer finds items in my PATH.  Finds them in the
> system path, but the "export PATH=$PATH:..." statement that I have in my own
> "~/.config/plasma-workspace/env/path.sh" file is ignored.
> 
> I suspect that the underlying cause is the same as what causes the issue
> described here, in that various ENV vars are no longer available to KRunner
> when it is executed, which would normally have been available to it.
> 
> Is KRunner now being started by some other process, and thus is no longer a
> child of "plasmashell" or "startkde" (or whatever script replaced
> "startkde")?

According to process tree in my system krunner belongs to systemd rather than any kde process. It's launched under my current user though.

This bug has been reported in RedHat Bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1754395) and seems to be fixed in systemd (https://github.com/systemd/systemd/pull/17188)

Thanks for the update!

*** Bug 431424 has been marked as a duplicate of this bug. ***

*** Bug 423059 has been marked as a duplicate of this bug. ***

So it seems this happens only on 1 of 2 of my machines, same Fedora 33 version, everything up to date. My desktop still exhibits this issues while my laptop which was a fresh install does not.

Didn't want to re-open the issue in case the problem is somehow this bug overwriting something making it permanent? Can anyone let me know where should i look for differences between the two systems?

env isn't being synced to DBus - there was a systemd bug/quirk where it rejects all env changes if one doesn't match it's arbitrary restrictions of what's valid.

Plasma 5.20 checked env values, but not the env names. 5.21 has that fixed

Fixed with
https://invent.kde.org/plasma/plasma-workspace/-/commit/10780187f57ab6e68fa08386321f2d0274b951df

*** Bug 434824 has been marked as a duplicate of this bug. ***