Summary: | >=kde-plasma/plasma-workspace-5.10.1 causes ~20 second delay in KDE confirmation pop-up windows | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | J.Borme <gentoo_bugs.nu_q5v> |
Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | alexey.min, gentoo_bugs.nu_q5v, itumaykin+gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.kde.org/show_bug.cgi?id=382444 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
J.Borme
2017-06-18 21:23:11 UTC
How do you launch your Plasma session? Did you properly configure your desktop, e.g. dbus and consolekit in default runlevel? (In reply to Andreas Sturmlechner from comment #1) I do not use the plasma desktop. I use x11-misc/slim and x11-wm/fluxbox, then I launch the KDE apps. Both dbus and consolekit appear in "rc-config list default". But then what is plasma-workspace doing on your system and how would it influence applications on a foreign WM? plasma-workspace was a dependency of notification-daemon due to USE=kde. I now removed the kde keyword, which allowed me to uninstall plasma-workspace. This is indeed a workaround for my problem, but still I think it should be ok to have more than one desktop environments on a computer, for testing and for the fun. I can confirm this bug here on Fluxbox, e.g. in dolphin and okular, and my observations suggest that it is connected to the notification sound that is played: In Dolphin: Normal behaviour: When deleting a document permanently (Shift+Delete), a (blocking) popup dialog (or notification?) is opened, asking whether one really wants to delete the selected item. This is accompanied by a system sound announcing the popup (a "blinggg"). Buggy behaviour while constructing the first such popup: After creating the popup window frame but before drawing its content, dolphin now hangs completely for approximately 25 seconds. Then the content is drawn and the notification sound is played. HOWEVER: When opening another type of dialog, which is neither blocking nor accompanied by a system sound like the properties window (Alt+Return), this popup window is drawn instantly, even if it is the very first dialog window that was created by this instance of dolphin. (The sound playing blocking popup window still locks up dolphin for some time the first time it is opened) In Okular: Normal behaviour: When a search (not starting at the begin of the document) reaches the end of a document, okular (usually) shows a (blocking) popup dialog (or notification?) asking whether one wants to continue from the beginning. This is accompanied by a system sound announcing the popup (a "blinggg"). Buggy behaviour while constructing the first such popup: After creating the popup window frame but before drawing its content, Okular now hangs completely for approximately 25 seconds. Then the content is drawn and the notification sound is played. HOWEVER: When opening a blocking popup window, that does not play a sound on construction like "Settings -> Configure Okular", this popup window is drawn instantly, even if it is the very first dialog window that was created by this instance of okular. (The sound playing blocking popup window still locks up dolphin for some time the first time it is opened) This suggests, that the problem is related only to popup windows / notifications that play a system sound on construction. Is this observation (that the bug only occurs on sound-playing popups) in accordance with the observation at kwrite? Any ideas how to narrow down the search field for this bug even further? Confirm with openbox and plasma-workspace-5.10.4-r2. https://phabricator.kde.org/D5968 - can this be the reason..? (In reply to Alexey Min from comment #7) > https://phabricator.kde.org/D5968 - can this be the reason..? Or, more precisely, this https://phabricator.kde.org/D5012 . But looking at code seems that waiter.h has: constexpr static const int dbusTimeoutSec = 60; not 20 or 30... (In reply to Alexey Min from comment #7) > https://phabricator.kde.org/D5968 - can this be the reason..? Reverting this change, i.e. plasma-workspace commit ab60c3b, doesn't help. Supposedly fixed upstream in https://cgit.kde.org/knotifications.git/commit/?id=1c97e1d9741fd15962474f47932dd09728dae76b Please backport into stable. Thanks, backported in git. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b868d154f825023aa7cab38852336e2c30d6d18e Please test. Haven't tested 5.34.0-r1, but tested 5.34.0 with the patch from commit on top and it helps a lot. There's still one observable issue with very slow tray icons appearance, but applications at least usable now. (In reply to Andreas Sturmlechner from comment #3) > But then what is plasma-workspace doing on your system Actually, the presence of plasma-workspace on the system is necessary to enjoy the Open File dialog (editable location bar, tree view, etc.) instead of the simpler Qt dialog. (See also https://www.reddit.com/r/kde/comments/3526u9/how_to_force_all_programs_to_use_kdialogs_file/ ) The Open Dialog in kate came back to normal now immediately after I emerged plasma-workspace (without ever launching plasma). Dialogs work good now. (Cannot say for tray icons, I do not use them.) Thanks for investigating and taking this upstream. The original issue seems to be solved, if there are remaining systray issues please open a new bug upstream. |