René J.V. Bertin posted on Wed, 27 Oct 2021 14:34:18 +0200 as excerpted:
> On Wednesday October 27 2021 12:19:47 Duncan wrote:
>
>> > (because wayland has no concept of primary screen
>
> Well that s*cks (I suppose)!
For most apps/windows in practice it's generally not /too/ bad because
kwin as compositor normally arranges the windows in line with whatever
window placement policy you've set, and as compositor it knows what
display your pointer is on so if you've ticked the active screen follows
mouse and separate active screen checkboxes in the window behavior kcm
(kwinoptions) it places windows as one might expect.
Between that and the kwin window rules kcm (kwinrules) for overriding
generally set behavior for specific windows (a feature of which I've
/always/ been a rather heavy user, 50+ rule-sets setup, IIRC), most
things work quite well.
The problem with krunner is that kwin makes plasma shell windows (like
the plasmoid picker and popup/config dialogs, panels, etc) exceptions to
its normal handling and considers krunner a shell window. Unlike most
other wayland-native windows plasma shell windows are basically unmanaged
by kwin -- plasmashell obviously knows screen sizes (not sure about
screen positions) and gets to place windows as it sees fit, while unlike
on X, for security reasons normal wayland-native windows know their size
but *not* on-screen position or the existence of other windows beyond
those of the same app. Only the compositor (and anything it specifically
passes the info to as an exception -- the compositor decides!), kwin in
this case, knows that information.
Which makes plasma shell windows (including krunner) immune to window
rules like placement-under pointer, etc. So without user-level patching,
there's no way to override plasma shell window positions. While that
works fine for most shell windows, krunner really needs more flexible
positioning than the current code allows -- in particular it needs window-
under-mouse positioning as an option, but apparently kwin hasn't yet been
setup to expose pointer position to plasmashell (except the normal
pointer positioning info active wayland windows get) so (at least in the
general some other window active case) plasmashell doesn't have the
necessary information to do window-under-pointer positioning.
Bugs are filed and they have responded that they know about it, the
necessary plumbing/wiring (as explained above) simply isn't hooked up yet.
So lacking window-under-pointer ability and with the two default position
options (top of top-left screen and semi-centered on the same screen)
entirely inappropriate to my use-case, I, being lucky enough to run gentoo
where it's not /horribly/ inconvenient and additionally, while not a dev,
being lucky enough to have the necessary knowledge for at least hack-
patches, hacked up my own hack-patch "at least it's usable for my use-
case" solution.
And I *definitely* appreciate the fact that this time around (as opposed
to the kde3/kde4 transition where if it couldn't be shell-scripted I
simply didn't have the necessary hackpatching skills) I can actually *do*
many of those hackpatches, and have taken full advantage of that fact!
=:^)
But few windows get the privs plasma shell windows get, meaning most
windows either behave reasonably with the default kwin config, or can be
individually configured with kwin window rules for default-exceptions.
Meanwhile, it's useful to be aware of another type of exception as well,
at least in the kde/kwin universe but it's being xdg standardized if it
isn't already, the OSD/on-screen-display popups, like the volume popup
the kmix and (I assume) the pulseaudio mixer plasmoids use. In this
particular case they're plasma shell windows and thus fall under that
exception as well, but the point of mentioning them separately is that
kwin has a whole z-axis positioning layer for these that *always* places
them on top of other windows, even normal layer "always on top" windows.
I'm not entirely sure that's in the wayland protocol xdg standards yet
and thus the degree to which third-party wayland apps can make use of it,
but they're working on it, and (obviously for non-plasma-shell windows
since kwin doesn't enforce window rules on them) kwin window rules
already has setting available to filter on this type of window as well as
force it and other window types such as normal.
That means that at least once things settle down a bit in wayland world,
wayland-native apps such as media players will be able to set OSD level
windows -- and kwin window rules is already setup to be able to filter on
and force OSD level on and off, configurable via window rule. Like I
said, useful info to know, tho the practical effect at this time is
somewhat less certain/useful. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
