06:25 <Industrial> Hi. I have this init file: https://gist.github.com/Industrial/1bef4dd2d9185bbd1a0d60b7f75a8d60#file-init-ts-L17 and this particular line doesn't seem to "work" while others do. When I copy the command and enter it in a terminal it says `overwrote an existing keybinding: normal Super+Shift P` and after that it starts working.

12:33 <leon-p> is it just me or is codeberg starting to get a bit slow on the rwm PR?

12:34 <ifreund> too many comments :/

12:35 <ifreund> to be fair, codeberg doesn't cheat by hiding 90% of the information behind (click to show more) buttons like github does

12:36 <leon-p> fair, and caching probably would grow their disk demand too much

12:41 <ifreund> leon-p: I don't have time for a detailed answer right now, but here's a quick example of the race I'm trying to explain:

12:42 <ifreund> say that clicking a button in a shell surface should open a new shell surface and give keyboard focus to that shell surface

12:42 <ifreund> also say the user starts typing as soon as they click the button as they know what it doe

12:43 <ifreund> do to the race, it is not guaranteed that the first keypresses after the click are routed to the shell surfaces

12:43 <ifreund> to the new shell surface that has just been given keyboard focus in response to the wl_seat pointer button event that is

12:44 <ifreund> in order to make that race-free, river would have to know to stop further processing of input events after it sends the wl_seat pointer button event

12:44 <ifreund> sorry for the terrible spelling

12:45 <vyivel> that doesn't seem solvable in general case

12:47 <leon-p> I see the issue. I'll think about that for while. Arguably the rest of my argumentation still stands though

12:47 <ifreund> maybe it's not worth solving and I'm just getting too hung up on it wanting things to be perfect

12:48 <ifreund> this race is solved for e.g. using a keybind to switch focus between windows for example

12:50 <leon-p> This race also exists f.e. a windows-esque task switcher in a bar

12:51 <leon-p> perhaps we could have a river_seat_v1:hold_back_input_events_until_...() event

13:52 <rederriver> Hi to everyone!

13:52 <rederriver> Someone is aware of this error on nixos?

13:52 <rederriver> error: The Wayland server does not support river-control-unstable-v1.

13:52 <rederriver> Do your versions of river and riverctl match?

13:52 <rederriver> using unstable

13:55 <LarstiQ> rederriver: yes

13:55 <rederriver> This error is caused by the nixpkgs?

13:56 <LarstiQ> no I mean both come from the same package in nixpkgs so they match, no problems for me

13:56 <rederriver> You're using unstable channel right?

14:27 <leon-p> arguably an obscure error if river was installed from repos, so unsurprisingly it's nixos...

14:28 <leon-p> they left, but if they read logs: you may be running riverctl under a different wayland server. no idea how you have to mis-configure your system to do that, but I know no other way to trigger that error message

14:35 <LarstiQ> one thing I can think of is updating the river package and getting a newer riverctl without restarting river, maybe

14:47 <ifreund> LarstiQ: all river versions so far support river-control-unstable-v1

14:47 <ifreund> it will be dropped in the future, but that hasn't happened yet

14:48 <LarstiQ> right. I have no clue what was going on then, I have never seen this afaicr on nixos

14:48 <ifreund> like leon said, they ran riverctl under a different wayland compositor than river

14:49 <leon-p> I already suspect that the version introducing the WM protocol will increase traffic in this channel quite a bit...

14:50 <ifreund> the first wave will be when we break river's master branch

14:50 <ifreund> the second wave will be when 0.4.0 is released

14:51 <ifreund> I'd like to have a reasonable "river-legacy" WM available when 0.4.0 is released

14:52 <leon-p> depending on what kind of WM you want to ship with river, it could be a switch 🤷

14:52 <ifreund> long term, I don't want any "default" WM

14:52 <ifreund> I do intend to ship a fallback WM with river that allows listing and executing other window managers

14:53 <ifreund> details very much TBD

14:53 <leon-p> then we need a specification for river to find WMs

14:53 <ifreund> probably yeah, but it shouldn't be much more than a path and environment variable

14:53 <ifreund> probably there's some XDG_* thing that already makes sense to use

14:54 <ifreund> or just repurpose .desktop files like is done for wayland sessions

14:54 <leon-p> we should probably also think about how river startup in general is supposed to work

14:54 <ifreund> idk, haven't given it much thought yet

15:09 <leon-p> ok the more I work on this widgets system the more I understand how GLib works internally and I am not sure if I like that, lol

15:11 <leon-p> it is certainly somewhat elegant to have nested structs to implement inheritance, even I don't plan on taking it quite that far

20:22 <Guest3630> exit