06:04 <dnkl> pretty sure fcitx5 doesn't implement the same version of the IME protocol as wlroots

06:04 <dnkl> it works in gtk apps because they use dbus(?) to communicate instead of a Wayland protocol

06:08 <dnkl> Though I seem to remember having fcitx5 partly working under sway, with foot. But suggestion popups didn't work, which meant typing "blindly"

06:11 <dnkl> https://codeberg.org/dnkl/foot/issues?q=fcitx5&type=all&sort=&state=closed&labels=&milestone=0&assignee=0

09:22 <nor[m]> Is there a way to always put the currently focused window to the top of the stack?

09:22 <nor[m]> I'm using river without any tiling, and it is sometimes confusing when I unfocus a window and it hides behind other unfocused ones because these are higher in the stack than the more recently focused one.

09:32 <novakane> not really the only way to change the order of the stack is with attach-mode which only works when a window is spawn, as the swap command doesn't works with floating window

09:35 <ifreund> nor[m]: yeah, I don't think river's rendering order for windows is ideal but I don't have any concrete ideas to improve it. Someone should probably investigate what exactly other (floating) window managers do

09:52 <nor[m]> > the swap command doesn't works with floating window

09:52 <nor[m]> It does. It just does not change positions, it only determines which window is covering the other when overlapping. It gets confusing, because the effect of the stack order is only visible when unfocused (focused windows are temporarily on top of all, but return to their stack position when unfocused). However, to change the order, the window must be focused and swapped through the stack "blindly".

09:58 <nor[m]> I am aware this is primarily a tiling compositor, please don't get distracted for the odd floating-only-user (me). I was just hoping to miss something obvious in the riverctl manpage. The zoom command does not perfectly help, but it does allow a manual "prioritize this window" action, so I'll probably just stick to that...

10:05 <novakane> yeah manually is your only option for now afaik

14:25 <leon-p> so apparently it is possible for clients to negatively rivers rendering or response time. I can reliably reproduce by having a single firefox instance open two windows, one per output. The mouse will move choppy. The two windows are somehow not equal: Switching to a different tag results in smoth mouse movement (on both outputs) only when done on a specific output (in my case the larger one, as expected). Playing a high refresh rate video "fixes" the issue, b

14:26 <leon-p> *negatively influence

14:36 <novakane> always firefox

14:37 <leon-p> yes :/

14:38 <novakane> maybe that something that would be fix by the scene graph

15:12 <ifreund> leon-p: I can't reproduce that, I commonly have multiple firefox windows spread across two monitors

15:13 <ifreund> the first thing that comes to mind from your description though is a damage tracking issue

15:13 <leon-p> to be fair, your computer is a bit better than mine, so it might be a performance issue

15:13 <ifreund> yeah, i've got a beefy desktop PC

15:14 <ifreund> the part where playing a high refresh rate video "fixes" it is what makes me thing it's not a performance issue though

15:15 <ifreund> pkap: dropped a comment on your mappings PR by the way :)

15:20 <pkap> Thanks ifreund!

16:15 <Guest7> Hi folks, I am trying out the river wm. First of all thank you for making this WM, so far loving it, just one question: How do I enable cursor follow to focus. It seems this feature is not enabled out of the box. I found few PR's mentioning this, but could not figure out on how to enable it.

16:17 <leon-p> Guest7: you mean warping the cursor to focused windows? That's not implemented, so you'll have to grab the PR and build that.

16:18 <leon-p> Maybe the PR also updates the docs

16:18 <ifreund> you might also mean `riverctl focus-follows-cursor enabled`

16:18 <ifreund> please see the riverctl man page

16:23 <Guest7> Thank you ifreund - `riverctl focus-follows-cursor normal/disabled` did the trick

16:53 <nor[m]> Is there a "recommended" or "better" way to map multiple actions to one keybinding than the following line?

16:53 <nor[m]> riverctl map normal Modifier Key spawn "riverctl action1; riverctl action2"

16:56 <ifreund> nope, that's the way to do it

16:57 <ifreund> if it's more complex you could always make a small script for the actions

17:06 <nor[m]> Alright, thanks. I think at 2 or 3 actions I'm fine with not splitting files. But I'm just goofing around right now, scripts will certainly be added once I use river full time. Probably will, I really love the tagging concept.