https://bugs.kde.org/show_bug.cgi?id=429177
Bug ID: 429177
Summary: wayland: krunner position no longer follows window
rules and can't be set to "under mouse"
Product: krunner
Version: unspecified
Platform: Gentoo Packages
OS: Other
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: alexander.loh...@gmx.de
Reporter: 1i5t5.dun...@cox.net
CC: plasma-b...@kde.org
Target Milestone: ---
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...
--
You are receiving this mail because:
You are watching all bug changes.
