Change:
Describe the bug When running Plasma Wayland, notifications and krunner pop-downs are treated like first-class windows and therefore take focus and appear in the task manager. This used to be an issue back in the day () so this is in all likelyhood something we do (wrong) on our side. To Reproduce Steps to reproduce the behavior: the steps in to get wayland running in to the plasma wayland session for a notification or trigger krunner the focus steal (for notifications) and appearance in the task manager Expected behavior Notifications and similar should not be treated as a regular window and therefore not show in task manager or receive focus (krunner should still have focus of course). Notify maintainers Cc: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs: References:
Oh, my intuition tells me this could be the root cause of the totally-wonky Plasma Mobile notifications.
- I found this: I haven't looked through the code yet (I'm not at all familiar with the plasma code) but it sure sounds like there is a disconnect between kwin, application and desktop file.
I don't think this is relevant to the "rendering" bits of the notifications. I'm not an expert either, but to me this sounds like it is concerned with the communication between apps and the daemon. BUT, "However, KNotifications uses the application name for identification rather than the desktop entry" is possibly a similar issue to the one we're having. But it's likely to be something concerning the kwin/KNotifications relationship, rather than KNotifications/app relationship.
The bug links says that the bug was fixed by these git commit back in the day:
So I've followed the instructions given to in the 2nd bug report Here are the properties of a notification window on Wayland: ! And here the same on X: ! !
Of note:Entire window class is on Wayland, on X SImilarly windows type is Normal window on Wayland, and apparently empty on X
where do you think we shpuld look specifically?
Nothing I can see is special casing on .
any news?
(All looked at under Plasma Mobile...) My current line of thoughts is that the window role is lost for some reason. This is supported by your previous screenshots, and my testing under Plasma Mobile shows me the same issue where window type is Normal. AFAICT this condition is never true: But if I force any clients to not accept focus, while it breaks some things, the notification does* stop taking over the focus. This is not a solution, far from it. I simply don't know how to debug this kind of issues, and am learning along the way how all of this is setup within kwin, plasma, and friends. This also does not affect the window sizing in Plasma Mobile, but it changes something for sure since it won't put the notification halfway off-screen. I would assume if the window never lost it
Can I trouble you to report your findings on the KDE bug tracker? I'm sure the guys over there are able to help.
I suspect is connected
I don't have much confidence in my findings. Reading through kwin's and plasma- and kwayland projects a bit hapazardly I found out that maybe it's totally expected that window roles are normal under wayland. Though I'm not confident either in those findings. EDIT: yeah, forcing the Notification role through for "type" dialogs in crashes Plasma Mobile :/. Whatever this means makes me think the window having the "Normal" window type is a red herring.
AFAIK solved that.
Looks like I'm stabbing in the dark, at random, and only hitting irrelevant bits. I'd need a KDE/Plasma person to take a better look at that. It is exhausting to look into, since I'm mostly learning everything from scratch on the spot.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Not yet fixed in 5.22 ! However I have also installed Grid WM and I found that the spectacle window got managed by Grid when on X11 it was not, and the window for unlocking kwallet does not get positioned in the center as it does in X11. Those put thogether suggest that somehow KWin thinks every window is a normal window. Also the properties of a notification window on wayland ! !
Also the Plasma entry in the tasks list shows up also on openin plasmoid menus like kickoff or the notification menu. Also the sound menu is put in the top left instead of bottom center !
Also also no clock widget
Ok how do we contact the KDE devs for guidance?
So here are the 3 commits that fixed this problem back in the day This suggest that window roles are not expected to be "Normal" for notification, especially since PlasmaShellSurfaceInterface::Private::setRole remain unchanged in master
So controlling the window type on a notification turn out that on X11 is revealed as empty. Follows wold,possibly incorrect speculation: this suggest that the Notification role somehow is broken and on X11 the broken role behaves like a notification but on Wayland it behaves like a normal window.
Devs, how can we, community, help to give some traction to this issue? Judging by the complexity of the issue, will setting up a bounty through help?
Most likely, it's not an issue about "traction" internal to Nixpkgs, but about talent knowledgeable in the intersection of [Kwin, Wayland, Nixpkgs packaging]. Most devs involved in this current discussion would be, I assume, knowledgeable with Nixpkgs packaging only.
That's my understanding too hence I'm trying to be creative here. Can someone with the write access try connecting to this repo and we'll give it a shot?
fyi there are bounty sites that dont need to be connected such as gitpay i have received a bounty via gitpay in and if needed the maintainer can help if there are issues
what sites you suggest?
I've edited bountrysource out of my comment because it appears that they've been acquired by a So I suggest gitpay since it's dev is active
Ok I've put $50 on it on gitpay
! (trying to make it to stick out)
Thanks, for recommending And let me know if any of you have any issues, and all feedback will be appreciated
i have seen this issue appid issue on other wayland programs where the appid is binname-wrapped im also experimenting with changing the wrapper to move the wrapped binaries to instead of . however that will require larger changes
instructions to test to the pr
It seems your fix is enough for plasmashell (notifications, this issue), but this mismatch between appIds caused by the wrappers seems likely to cause issues with any other wrapped GUI app on plasma wayland. Would there be a generic fix to ensure any wrapped app keeps its correct ?
im looking in to it
This issue is not caused by appid, but something else PR fixes appid, but this issue is still present !
Seems like this issue is in plasmashell itself, i can see this via But no other surface created by plasmashell receives role
plugin is responsible for this (It provides ), but just adding it to doesn't help, because is patched to be pure, and only load plugins from itself: ( is defined at build time) We also can't just add to its path, as this package itself depends on kwindowsystem The only way i see here - make plugin loading impure (by removing this patch), and rely on existing being set here:
Starting session via with and applied on top of fixes this issue
(Tangentially related, I'll be trying with the plasma-mobile PR tomorrow. Hopefully this is what fixes the issues there too.)
do you have a good enough mental model of what is happening to know if, instead of (ab)using the environment through tons of wrappers, we'd instead ? Note that I'm not talking about "unwrapping" the name of . I'm talking about the general idea of making Qt aware of library paths through a declarative and pure (enough?) method that does not rely on an unreliable method like the environment and wrappers. I still think that using wrappers and the environment is the worst misfeature in NixOS integration we're still doing. (Not specific to Qt.)
If the wrapper magic is the problem, I wonder if the "proper" solution would also make screensharing/recording via pipewire, ssh-agent and fcitx (and presumably other IMEs) finally work on wayland as well.
unlikely that it alone would be the fix, but it might be part of making things easier. It seems that their design for Wayland application "authentication" relies, among other things, on looking at the application names (from ), finding either the desktop file or dbus description for said app. This is where "unwrapping" is currently needed. Without unwrapping, either directly the application name is wrong, or the desktop file / dbus files for don't exist. Then there's the possibility that "" Qt plugins aren't found if a wrapper is missing or misconfigured. Though that one is less likely to be an issue, assuming the wrappers are configured. It's possible every service needs to be tracked down to their hardcoded special casing in the different Wayland components to know for sure how they work.
fixes works for Plasma Mobile! <details<summary:computer::camera: Screenshot </summary! </details
I agree with that qt wrapping is a mess, but i see the better story with qt plugins much as something like: Patch qt to load plugins from something like (I.e would load plugins from ) Add nixos module to define plugin directories: This way it would be explicit, and pure enough to not break things with errorously loaded plugins
Breaks on non-NixOS systems, user profiles or . The way I implemented in that old PR was pure from the inputs of a given derivation, while still staying compatible with the less pure automatic loading of plugins from profile directories that is already in use. Though this discussion should probably be had elsewhere than this specific issue... Sorry for starting to roll the ball about that in the wrong location :).
Reopening; I think it also requires , though I never tested for myself.
isn't required for this fix, but it fixes other possible problems, kwin has some plugins with hardcoded s, i.e uses this to blacklist animation on shell surfaces
Huge thanks for fixing this! Can someone else confirm it solves the problem for them? (we need to release the bounty :)
With applied running in a terminal does indeed no longer steals focus from typing this comment in my browser. The notification also doesn't show up in the task manager.
I can also confirm several other plasma wayland issues I was experiencing got fixed by : blur on plasmoids, panel, yakuake/konsole are working again; before, I was only getting normal transparency and no blur some other plasmoids popups besides notifications were also stealing focus and having an entry on taskbar, including launcher volume/brightness HUD were also stealing focus, and were always localized on the top-left corner of the screen; they now appear in the center, as on X11
can you please submit at the as a solution (to claim the bounty)? !
I tried to do that before, but "The issue is closed on GitHub" check is missing, i though there is some confirmation required from issue creator !

Discussion:
kwallet-pam kwalletmanager kwayland <ins> kwayland-integration </ins> kwidgetsaddons kxmlgui kxmlrpcclient

<del> From 291f691400d4e85c57b57ec75482d2c6078ce26e Mon Sep 17 00:00:00 2001 From: Thomas Tuegel <ttuegel@mailbox.org> Date: Wed, 9 Dec 2020 10:01:59 -0600 Subject: [PATCH] platform plugins path --- src/pluginwrapper.cpp | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/src/pluginwrapper.cpp b/src/pluginwrapper.cpp index a255d83..9699b08 100644 --- a/src/pluginwrapper.cpp +++ b/src/pluginwrapper.cpp @@ -25,20 +25,19 @@ static QStringList pluginCandidates() { QStringList ret; const auto paths = QCoreApplication::libraryPaths(); -    for (const QString &path : paths) { -        static const QStringList searchFolders{ -            QStringLiteral("/kf5/org.kde.kwindowsystem.platforms"), -            QStringLiteral("/kf5/kwindowsystem"), -        }; -        for (const QString &searchFolder : searchFolders) { -            QDir pluginDir(path + searchFolder); -            if (!pluginDir.exists()) { -                continue; -            } -            const auto entries = pluginDir.entryList(QDir::Files | QDir::NoDotAndDotDot); -            for (const QString &entry : entries) { -                ret << pluginDir.absoluteFilePath(entry); -            } +    const QString path = QStringLiteral(NIXPKGS_QT_PLUGIN_PATH); +    static const QStringList searchFolders { +        QStringLiteral("/kf5/org.kde.kwindowsystem.platforms"), +        QStringLiteral("/kf5/kwindowsystem"), +    }; +    for (const QString &searchFolder : searchFolders) { +        QDir pluginDir(path + searchFolder); +        if (!pluginDir.exists()) { +            continue; +        } +        const auto entries = pluginDir.entryList(QDir::Files | QDir::NoDotAndDotDot); +        for (const QString &entry : entries) { +            ret << pluginDir.absoluteFilePath(entry); } } return ret; -- 2.28.0 </del>

nativeBuildInputs = [ extra-cmake-modules ]; buildInputs = [ libpthreadstubs libXdmcp qttools qtx11extras ]; propagatedBuildInputs = [ qtbase ]; <del> patches = [ ./0001-platform-plugins-path.patch ]; preConfigure = '' NIX_CFLAGS_COMPILE+=" -DNIXPKGS_QT_PLUGIN_PATH="''${!outputBin}/$qtPluginPrefix"" ''; </del> outputs = [ "out" "dev" ]; }