Bug 429177

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...