lol.
-
@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@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
-
@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
@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@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.
@sodiboo oh actually hi hello since you are involved in niri already: does niri support per-window GLSL shaders?
-
@sodiboo oh actually hi hello since you are involved in niri already: does niri support per-window GLSL shaders?
@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. -
@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.@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@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@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@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.@sodiboo wait does niri not support background blur already?
-
@sodiboo wait does niri not support background blur already?
@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@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)@sodiboo .. ok how hard would it be to hack shaders into niri
-
@sodiboo .. ok how hard would it be to hack shaders into niri
-
-
-
@sodiboo .. ok how hard would it be to hack shaders into niri
@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. -
@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.@49016@mastodon.catgirl.cloud did I hallucinate a cosmic-comp PR why can't I find it
-
@49016@mastodon.catgirl.cloud did I hallucinate a cosmic-comp PR why can't I find it
@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 -
@49016@mastodon.catgirl.cloud did I hallucinate a cosmic-comp PR why can't I find it
@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 -
@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
