New task manager

[Duncan]

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