04:45 <fleurc> Hi, just wanted to say that I solved the gpg issue today, it was both an environments not set issue and an xdg-desktop-portal issue. Essentially, for future reference: Have both XDG-DESKTOP-PORTAL and XDG-DESKTOP-PORTAL-WLR installed. Then execute both with "/usr/lib/xdg-desktop-portal -r & /usr/lib/xdg-desktop-portal-wlr &" and finally update the environments with "systemctl --user import-environment WAYLAND_DISPLAY

04:45 <fleurc> XDG_CURRENT_DESKTOP" and "dbus-update-activation-environment SEATD_SOCK DISPLAY WAYLAND _DISPLAY XDG_SESSION_TYPE=wayland MOZ_ENABLE_WAYLAND=1 RTC_USE_PIPEWIRE=true XDG_CURRENT_DESKTOP=river". This way GPG works like a charm.

04:45 <fleurc> It's 1am, gotta go now, thanks for the answers (The archive is real useful since Circe in Emacs doesn't save chats)

06:31 <leon-p> starting to think the WM protocol is a trick to make us all understand how the transaction system works, since now any WM needs one too :)

06:31 <larstiq_> haha

08:03 <tiosgz> how you know leon-p is working on a wm :) (at least in their mind)

08:04 <tiosgz> i may need to think about this more, but i've had the impression the wm can simply send everything to the compositor right away?

08:06 <leon-p> yes, but message order isn't defined. so you really should do most logic in response to the river_window_manager_v1.update event

08:15 <tiosgz> i'm not sure if there's something in wayland i'm unaware of, or if i'm not getting the consequences

08:16 <tiosgz> msg order isn't defined, as in you don't know if you've sent this earlier than received that, or that you don't know if what you send is in the order you've sent it?

08:16 <tiosgz> (in the latter case that would be new to me)

08:17 <leon-p> events you receive were sent in that order, request keep their order as well

08:17 <larstiq_> but no ordering between receive/sent?

08:18 <leon-p> not really, but that is also not what I meant

08:18 <leon-p> there can be multiple events in a single update, which may affect the same resources

08:18 <leon-p> so you want to collect all changes until the update event

08:18 <tiosgz> ah, right. just got that the moment you started writing it :)

08:19 <tiosgz> thanks

08:19 <leon-p> f.e. a new window appears and your outputs usable dimensions change in a single update. depending on which came first, the initial position of the new window may be different

08:20 <leon-p> by collecting all changes and handling them in a defined order in your update event handler, you can work around that

08:20 <leon-p> f.e. always do all output changes first, then do all window changes.

08:21 <leon-p> I am reasonably sure some seat related things can sidestep this without issue, but I need to try this in practice

08:22 <leon-p> also for a new window you'll want to wait for app-id, title, geometry anyway before you do anything with it

08:22 <ifreund> some bad clients may not set app-id before you send them the first configure :/

08:23 <leon-p> also true

08:23 <ifreund> in any case, I dont think what WMs need to do here for frame perfection is anywhere near as complex as rivers transaction system

08:24 <ifreund> and I dont think its unique to this protocol either, double buffered state is common across many Wayland protocols

14:16 <leon-p> this is so much boilerplate. after a few hours typing on-and-off I am almost at the point where I can write the interesting bits https://git.sr.ht/~leon_plickat/river-wm/tree/master/item/wm.c

14:16 <leon-p> the amount of boilerplate is a failing of wayland and libwayland more so than the protocol, so that's not a complaint :)

14:29 <ifreund> leon-p: yeah, this kind of thing is much better with zig-wayland: https://codeberg.org/river/river/src/commit/5ea8bb8f5f8aa8b75a72880d9733869e7a3af339/river/Window.zig#L418-L424

14:29 <ifreund> most of these trivial state update things are just one line in a switch statement

14:32 <ifreund> In any case, I think there's space for an official librwm library to handle as much of that boilerplate as possible

14:33 <leon-p> yeah I would like to use zig, I just don't want to add another project to the list of things I have to work on twice a year when a new zig version is released :/

14:33 <ifreund> totally fair :)

14:34 <ifreund> I think zig will trend towards stability with releases becoming less and less breaking over the next few years

14:35 <leon-p> language breaking changes aren't the problem, changes to std and the build system were quite tedious so far however

14:35 <leon-p> the nice thing about C is that I won't have to touch the code again until I either want to add a feature or fix an issue

14:37 <ifreund> yeah, I totally agree about writing small things that are feature complete in C for now

14:38 <ifreund> Zig is more worthwhile the large the project is and the longer you plan to actively develop/maintain it

14:38 <leon-p> agreed

14:39 <leon-p> maybe in ~10 years or so there is a gcc frontend for zig, then I'd say you could also use it for small programs you don't want to touch again

19:36 <angle> hey my numlock and CAPSLOCK keys aren't lighting up when they're activated.

19:37 <angle> they still work, but I'm curious if this is a known issue cause they light up normally with dwl and sway.

20:20 <leon-p> angle: it may be that they are on a separate logical keyboard (which can happen despite being the same physical device). In that case you can set up a keyboard group which will make all the logical keyboards act as a single one

20:31 <angle> I'm not sure what that means.

20:31 <angle> leon-p: I use keyd and messed around with some plugdev settings when I was getting dotool to work at some point.

20:33 <angle> okay, I see a section on keyboard groups in riverctl man page.

20:33 <angle> I will read the docs then.

21:03 <ifreund> Ill be away over the weekend, back Monday or so :)