12:28 <user181308142001> Hi everyone, I was just wondering, I have been using river for a while now and am interested in it''s continued development. Is there some way in which I can send a one-time financial contribution to the project (preferably using crypto currency)?

13:26 <ifreund> user181308142001: Hello, thanks for your interest in the project! I don't have anything set up for donations at the moment but I could email you my paypal if you like

13:27 <ifreund> not much of a crypto user myself, but what currency do you use?

13:28 <ifreund> I started getting github sponsors set up a while back but got distracted, I should probably finish that

13:30 <user181308142001> ifreund: Paypal would be great, you can email me at wester.t@protonmail.com ( if you want, I have a pgp public key here https://twester.tk/ssg/contact.html). I personally keep a bunch of crypto like Bitcoint, Etherium, Monero, BAT, Tezos and others (basically all the big ones and more)

13:31 <ifreund> user181308142001: cool, I'll send you an email in a few minutes, my pgp key is here: https://ifreund.xyz/public_key.txt

13:52 <ifreund> user181308142001: mail sent :)

17:11 <snakedye> I had a thought. Is it necessary to have the layout name in the commit? I think it should be a separate request because most layouts won't change name on every layout request.

17:18 <ifreund> snakedye: what would be gained by making it separate? just less traffic on the wayland connection if the layout doesn't want to set the name?

17:22 <snakedye> Mostly. I imagine river-toplevel-v1 would have to advertise a client the same layout name each time a layout request is made. Also cloning Strings repeatedly triggers my ocd 😅

17:23 <ifreund> why do you need to clone strings if your name never changes?

17:24 <snakedye> I can't send a string slice

17:25 <ifreund> then that's a issue with the wayland library you're using

17:26 <ifreund> (that's not the only non-zero-cost abstraction in wayland-rs by the way, there's a lot of ref-counting too)

17:27 <snakedye> Ultimately a String would have cloned some point out another. I doubt I can send a reference to a string to the server

17:28 <ifreund> snakedye: ultimately the bytes of the string need to be written to the wayland socket. There is no need to clone these bytes to a new buffer before writing them to the socket

17:29 <ifreund> cloning the string doesn't change the bytes contained, and doesn't in any way affect what the wayland server will recieve

17:33 <snakedye> I agree that it's inevitable that the bytes will be cloned but my point was rather that there's no need to clone them at the current frequency.

17:38 <ifreund> snakedye: right now wayland-rs does 2 copies as the functions to send requests take a String instead of a slice, only 1 copy is strictly needed

17:38 <ifreund> s/2 copies/at least 2 copies/

17:39 <ifreund> the "1 copy" i'm talking about isn't even really a copy

17:39 <ifreund> it's just writing data to a socket

17:39 <ifreund> you're right that moving the layout name out of the commit request would reduce traffic on the wayland socket if the layout client doesn't need to set the name on every commit

17:41 <ifreund> I think it's a good point and we should include it in v4 of the protocol, but that small change alone is not worth breaking backwards compat for

17:48 <snakedye> Will v4 come after 0.1.0? Since you're busy right now it's not really urgent

17:49 <ifreund> snakedye: yes, probably

17:50 <ifreund> There's nothing major enough I want to change to be worth breaking v3

18:36 <leon-p> we probably should have a GH issue to collect all the change proposals for the next layout protocol version so they don't get lost

18:39 <leon-p> snakedye: compared to other protocols river-layout has very few events / requests in any given amount of time, so IMO sending the same string multiple times is not a big deal.

18:39 <leon-p> I am more concerned with /generating/ the string rather than sending it, since some clients may want to put information there.

18:40 <leon-p> but again, it's not send often enough to be a problem

18:57 <ifreund> leon-p: https://github.com/ifreund/river/projects/1

18:59 <ifreund> leon-p: also, would you like triage permissions for the repo to edit projects/issues and whatnot?

19:03 <leon-p> ifreund: that would be nice, thanks

19:05 <ifreund> leon-p: invite sent

19:06 <ifreund> I think I may have actually given you permission to push to master as well... Github doesn't seem to have very finely grained access controls

19:07 <leon-p> ifreund: don't worry, I only push to master on my own projects :P

19:09 <ifreund> leon-p: cool, thanks. It looks like I could get more finely grained access controls if I made an organization, but I don't really feel like doing that.

20:46 <novakane> what's the difference between Listener.init() and Listener.setNotify()?

20:49 <ifreund> novakane: init() returns a new listener struct by value

20:50 <ifreund> as you can see in the source code of zig-wayland, all it does is call setNotify()

20:53 <novakane> ifreund: thanks, yeah that's why I was wondering what was the point

20:54 <ifreund> setNotify() came first as it matches the libwayland api

20:54 <ifreund> init() was added as it can be used to initialize listener fields with a default value

20:55 <ifreund> if you want to change the notify function after initialization, init() won't work though

20:56 <novakane> okay makes sense, thanks

20:57 <novakane> I'm fighting with pointer with the input method implementation so I was looking a bit at the Listener source code