13:38 <snakedye> leon-p: does wlopm take '*' for all outputs?

13:40 <ifreund> snakedye: not yet though I think that's planned, see the logs from yesterday

13:41 <snakedye> alright 👍

14:11 <leon-p> snakedye: now it does

14:11 <leon-p> elshize: ^

14:14 <snakedye> yay :p

14:22 <ifreund> the more I use river on my multi montior setup, the more I want to make the view stack global across all outputs

14:23 <leon-p> how would that imrove the multi-monitor experience?

14:25 <leon-p> and have you had some time yet to look at my two multi-monitor related PRs?

14:26 <ifreund> I think that instead of having 2 steps to focus a tag on a non-focused output (focus output, focus tag) there could just be one

14:27 <ifreund> leon-p: I'm not sure I like warping the cursor on output change personally, maybe we could make that a config option?

14:27 <leon-p> tags or specific views? Because for the latter I think marks would be more useful

14:27 <leon-p> ifreund: sure, can make it optional

14:28 <ifreund> leon-p: I was thinking tags, though maybe marks would address my use-case

14:29 <ifreund> kinda hard to know without implementing one or the other and trying it for a week

14:29 <ifreund> whichever one we go with though, that should happen after 0.1.0

14:29 <leon-p> maybe we could implement foreign toplevel focusing. then give your views special app-ids.

14:31 <ifreund> hmm, that's another idea

14:33 <leon-p> The problem is to decide whether "toggle that tag" or "focus only that tag" is the correct action for a foreign toplevel activation request

14:33 <snakedye> is having tags associated to multiple monitor something you would consider?

14:34 <snakedye> I have one where I just have a terminal with ncmpcpp and it would be more effecient to call it anywhere than just on one output

14:34 <leon-p> I personally would prefer if we avoid that. A shared set of workspaces for all outputs is one of the major reasons I am not on sway anymore.

14:36 <snakedye> the thing with sway is that all workspaces are like this. i think this model works much better with scratchpads

14:38 <leon-p> it's just to inconsistent for my taste. Will focusing a workspace do something on this output or on the other? I don't know until I do it.

14:41 <snakedye> the idea is that it will always do something on the focused output but it can be invoke from anywhere

15:35 <ifreund> elshize: did that latest patch really fix the issue with mako? cause I don't think it should have

15:35 <ifreund> https://github.com/emersion/mako/blob/445bf2d28d162007507580c40c9265978736f148/wayland.c#L563-L565

15:35 <ifreund> it could be seen as a mako bug tbh but I think river should do the right thing and send a configure here

15:36 <ifreund> working on the code to do that now

15:50 <leon-p> ifreund: regarding foreign toplevel activation, the changes required are trivial. My patch froma few weeks ago to allow focusing views via pointer on unfocused outputs does most of the work already.

15:50 <leon-p> I submitted a simple PR

15:50 <leon-p> I am not sure the behaviour (switching focused tags to the active tags of the view) is what we want, but it works

15:57 <leon-p> if you neew a CLI foreign toplevel client, this one works well: https://git.sr.ht/~brocellous/wlrctl

15:59 <ifreund> does the wlroots example not work?

16:00 <leon-p> it probably does, I just tend to overlook those examples

17:10 <ifreund> finished what I think is the proper fix for the mako issue, if anyone who was able to reproduce the race condition could test it that would be much appreciated

17:10 <ifreund> https://github.com/ifreund/river/pull/336

21:29 <ifreund> got xbps-src cross compiling zig code that links system libraries :) https://github.com/void-linux/void-packages/pull/29288

21:29 <ifreund> which will be great for packaging river