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