lol.

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud That makes some sense I guess; I actually see this being useful perhaps. But it's not what I expected initially. And I do know this means I have a client implementation that I need to test if this completely breaks it.

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud interesting. if I am holding a left click on one surface, the next surface does NOT ever receive a mouse enter or position events until I let go of the click.

it's not like, a bug, this isn't an issue. but I didn't know this.

I also realize that this implies, subtly, that clicking while moving a cursor over a window is sufficient to prevent any pointer constraint of that window from activating. so if a window has a pointer constraint that one needs to bypass, just click while moving over that window! problem solved!

I also realize that this implies, subtly, that software KVM switches like lan-mouse that depend on layer surfaces at the edge of the screen, cannot let you move across machines if you hold left click. this is actually a usability issue. what they are doing is basically a hack though; it's not expected to work perfectly. it probably doesn't need fixing

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud niri's hot corner is consistent with everything else here: you cannot activate it whilst holding a left click. this one was surprising to me because I expected it to override this focus behaviour since it's compositor managed but I guess not; the hot corner obeys regular pointer focus rules

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud actually I see why hot corner doesn't activate here: a full screened app also stops it from activating; as it should. this is probably the reason that the hot corner follows regular pointer focus rules and hit tracking.

⬡-49016 :neobot_box_cat_ears:

@sodiboo oh actually hi hello since you are involved in niri already: does niri support per-window GLSL shaders?

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud uhm uhh . no. I don't think so.

it supports defining like, three different custom shaders for specific animations you can customize, but they don't get any window metadata and can't be controlled by window rules.

I assume by "per-window shaders" this specifically means always-active shaders decorating a pariticular window in its regular non-animating state? if so, I believe that has been asked about before, and from what I remember, it wasn't implemented due to concerns about the performance of long-running custom shaders.

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud what, specifically, is it looking to accomplish with per-window shaders? is there a particular effect it wants to achieve? or just to play around with the capability?

⬡-49016 :neobot_box_cat_ears:

@sodiboo transparency everywhere. it is a sucker for some good blur and the easiest way to get it to work consistently is a shader that does a bit of chroma-keying

it works pretty darn well on h*pr with a custom shader; it eats a bit of gpu but not noticeably

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud ooh! window transparency and blur is really cool yes.

currently, no, niri does not support this kind of thing. closest one can get is just regular transparency without any blur.

but, there is a new background effect protocol, and once that is implemented in niri, it will have the capability to do, well, background effects! such as blur!

and then, perhaps not right away, it can even be generalized to support custom shader background effects as a window rule? idk I'm not totally familiar with graphics code but like this sounds plausible methinks.

⬡-49016 :neobot_box_cat_ears:

@sodiboo wait does niri not support background blur already?

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud no. unfortunately not. no blur effects anywhere.

(but it is now a standardized Wayland protocol, so if someone wants to add background blur it should be fairly straightforward to implement that protocol probably)

⬡-49016 :neobot_box_cat_ears:

@sodiboo .. ok how hard would it be to hack shaders into niri

olivia, :neofox_flag_sapphic: :neofox_flag_trans:

@49016 @sodiboo there's shaders for other purposes (animations and stuff)

⬡-49016 :neobot_box_cat_ears:

@oli @sodiboo ok so would it be possible to just add a, well, idle animation to windows

olivia, :neofox_flag_sapphic: :neofox_flag_trans:

@49016 @sodiboo i don't see why it wouldn't be possible

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud honestly no idea. I've only barely touched the rendering code and I'm not very familiar with EGL.

but COSMIC has an implementation of background blur that's... in the works I think? a PR? maybe it was merged? should be a decent thing to work from since both use the same rendering primitives from Smithay.

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud did I hallucinate a cosmic-comp PR why can't I find it

sodigay :pride_heart: forever

@49016@mastodon.catgirl.cloud oh maybe this is the one I saw. https://github.com/Smithay/smithay/pull/1758

even better then, Smithay itself implementing it generally would be even easier to implement in nori than ripping it out of another compositor.

but it's not finished and still marked draft so I have no idea what it's like to use at this state; I haven't looked at it closely

olivia, :neofox_flag_sapphic: :neofox_flag_trans:

@sodiboo @49016 i'm not sure there was

i do know that nferhat implemented blur in fht-compositor and then visualglitch91 ported it to a pr for niri

github.com/YaLTeR/niri/pull/1634

olivia, :neofox_flag_sapphic: :neofox_flag_trans:

@sodiboo @49016 i wouldn't have guessed the protocol name

The Fedi Forum

lol.