Bug 429177

Summary: wayland: krunner position no longer follows window rules and can't be set to "under mouse"
Product: [Plasma] krunner Reporter: Duncan <1i5t5.duncan>
Component: generalAssignee: Alexander Lohnau <alexander.lohnau>
Status: RESOLVED DUPLICATE    
Severity: normal CC: aldo-public, ashark, isma.af, kishore96, mail, nate, plasma-bugs
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Other   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: hackpatch: krunner to bottom-right of its default screen

Description Duncan 2020-11-16 01:49:13 UTC
Krunner, kwin windowrules or the configuration in plasma systemsettings, this could arguably be filed under any of them...  Version is live-git plasma/frameworks/apps from the gentoo/kde overlay.

So the last week or so I've finally found plasma-wayland "good enough" to start porting my own setup and workflow... and filing bugs where it's still broken.

The basic problem is that krunner's config needs a third position choice, "under mouse".

Sparing you paragraphs of details I had in my original description both top-of-screen and screen-centered are entirely inappropriate here.  Where I really need krunner is right where my focus is, "under mouse".  But that's not a given option. =:^(

That's the root bug, which by itself would be a dup of the 6-year-old bug #335730, except on X I've been happily using the window rules work-around to force krunner under the mouse where it belongs, and I've just been glad kde/plasma's advanced enough to provide such options.

But... now that I'm switching to wayland the window rule is broken and can't be fixed via config only.  I can update all the matching, the detect window properties button still works on krunner-wayland, but the "under mouse" positioning simply doesn't work.

Furthermore, the thing insists on coming up on the secondary monitor, when the mouse and all the other windows are on the primary (yes, even with ignore requested geometry on and obey geometry restrictions off, which worked on X).  I even tried forcing the screen, and it simply ignored that as well.  It's *ALWAYS* centered on the secondary, which due to the size of my big-screen TVs as monitors and because my normal focus is on the primary, tends to be far closer to inline with my ear than my eyes!

But it's a video monitor not a speaker, and I don't see with my ear!

Because on wayland it's insisting on the secondary when all the other windows come up on the primary, and because it's ignoring basically all the rules I try, I suspect the problem may be that on wayland it's an unmanaged window that kwin doesn't position, which makes the inability to enforce the window rule a krunner bug, not so much a kwin bug (altho with ignore requested geo on and obey geo restrictions off, arguably it's a kwin bug that it can't then force things).

So I'm filing it under krunner.


Meanwhile... something about writing it down... Assuming it /is/ an unmanaged-window problem... I'm not a dev but I am a gentooer running live-git kde so I'm rebuilding it all the time anyway, I wonder how hard it would be to come up with a patch to make it managed...  I'd thought about trying to hack-patch in an under-mouse option but figured it'd be near the limits of my ability, but finding and hack-patching whatever identifies the window as unmanaged to make it managed might be easier...  But I've still got other bits of my to-wayland workflow-port to worry about first...[1]

---
[1] Tomorrow I'll probably be working on scripting dbus calls to kglobalaccel to trigger kwin's the zoom effect.  The problem there is the "extra" zoom keys on the keyboard, which the kernel and libinput see, but kglobalaccel and the shortcut kcm on wayland can't.  I /was/ using evrouter to translate to X events the shortcuts kcm and kglobalaccel could see, but that doesn't work on wayland, so I gotta add another layer or two, having evrouter call a bash script to issue dbus calls via qdbus or dbus-send to kglobalaccel.  Preliminary manual testing via qdbusviewer says it'll work but I still have to code it up. ... Tomorrow...
Comment 1 Duncan 2020-11-29 16:00:53 UTC
Created attachment 133730 [details]
hackpatch: krunner to bottom-right of its default screen

This is the worst paper-cut bug remaining from my switch to wayland, that I haven't at least hacked around... until this hack-patch anyway.

Not being a dev I haven't been able to trace down what in (presumably) kwin is forcing it to ignore window rules for krunner (I did try patching something that looked like the possible culprit and ended up spending several hours trying to recover after the experiment went horribly wrong and screwed up my plasma config and getting it back wasn't as easy as simply replacing plasma-org.kde.plasma.desktop-appletsrc with a backup), but...

This at least forces placement to the bottom-right of the screen it defaults to, making it easier to use as it's at least /close/ to my normal focus at the bottom-left of the screen just to the right.
Comment 2 Alexander Lohnau 2020-12-07 19:46:47 UTC
Actually KRunner is supposed to follow the mouse, but on wayland there is currently no way of getting the cursor position. Also there is no primary monitor concept, which could be a workaround.
Comment 3 Duncan 2020-12-08 08:01:56 UTC
(In reply to Alexander Lohnau from comment #2)
> Actually KRunner is supposed to follow the mouse, but on wayland there is
> currently no way of getting the cursor position. Also there is no primary
> monitor concept, which could be a workaround.

I'd read about wayland lacking the primary monitor concept in other bugs.  Unfortunate.

As for follows-mouse, kwin as compositor has to know the mouse position, correct?  And it can enforce under-mouse on other windows -- I have a kwin window placement rule that does just that for the troublesome appmenu-in-titltebar menu-popup, which otherwise follows the general least overlapping rule and ends up way across the screen -- troublesome when you have focus-follows mouse set as you can't get there without changing focus away from the window whose menu you are trying to work with.

Unfortunately, apparently krunner is a plasmashell window, and plasmashell windows get to override kwin's window rules, even user-set ones! (I've seen that mentioned in other bugs.)  That explains why krunner ignores the under-mouse window-rule I've set for it.  If I could just find out where that ignore was coded I could try to hack-patch that out and my krunner window rule would work as it should.  But so far that has eluded me.
Comment 4 Andrew Shark 2021-04-25 18:23:34 UTC
Found a similar bug about yakuake: Bug 411681
If that gets solved, probably the method of getting screen with mouse could be used here as well.
Comment 5 Aldoo 2021-09-23 12:07:26 UTC
Another side effect of this bug: when exiting krunner, the focus doesn't necessarily go back to the window that previously had it.

Instead it goes to the active window of the left screen, which is particularly frustrating when the screen you use as primary is on the right hand side.

This behavior probably deserves its own bug. This bug was invisible when krunner used to correctly appear on current screen. But even if #429177 is fixed, the focus bug could come back when screen placement options will be implemented in krunner.
Comment 6 Aldoo 2021-09-23 12:07:51 UTC
By the way, this focus issue also affects Yakuake.
Comment 7 Kishore Gopalakrishnan 2022-03-27 11:40:50 UTC
Duplicate of bug 427069 ?
Comment 8 Duncan 2022-03-27 17:48:06 UTC
(In reply to Kishore Gopalakrishnan from comment #7)
> Duplicate of bug 427069 ?

Seems to be.   Thanks.

*** This bug has been marked as a duplicate of bug 427069 ***