lol.
-
lol. mouse follow mfm is cut off at note border but it still tracks the pointer so on mobile if I tap above and below the post, the pointer element will just zoom by inside the post frame
-
lol. mouse follow mfm is cut off at note border but it still tracks the pointer so on mobile if I tap above and below the post, the pointer element will just zoom by inside the post frame
@sodiboo fun fact on desktop browsers clicking dragging allows js to track the cursor outside of the window boundary which has hilarious consequences to mfm
-
@sodiboo fun fact on desktop browsers clicking dragging allows js to track the cursor outside of the window boundary which has hilarious consequences to mfm
@49016@mastodon.catgirl.cloud hm . doubtful that this will work on my machine because i have a wayland desktop
-
@49016@mastodon.catgirl.cloud hm . doubtful that this will work on my machine because i have a wayland desktop
@sodiboo nope! works on wayland as well
-
@sodiboo nope! works on wayland as well
@49016@mastodon.catgirl.cloud but how? what. there's no way windows get mouse position if the mouse isn't on the window. what. I gotta test this now
-
@49016@mastodon.catgirl.cloud but how? what. there's no way windows get mouse position if the mouse isn't on the window. what. I gotta test this now
@49016@mastodon.catgirl.cloud Oh! it DOES work! mouse leave only occurs when the click is RELEASED and absolute position events to negative coordinates are absolutely sent!
-
@49016@mastodon.catgirl.cloud Oh! it DOES work! mouse leave only occurs when the click is RELEASED and absolute position events to negative coordinates are absolutely sent!
@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.
-
@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.
@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 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
-
