ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
maringuu has quit [Ping timeout: 250 seconds]
maringuu has joined #river
snakedye has quit [Ping timeout: 240 seconds]
maringuu has quit [Read error: Connection reset by peer]
maringuu has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
yyp has joined #river
n8r has joined #river
<n8r> any laptop users here? what do you use to manage your wifi connections?
<yyp> n8r: most people recommend networkmanager + wifimenu/nm-applet
<yyp> Though, I haven't tried either on river as I'm not really a laptop user
n8r has quit [Ping timeout: 240 seconds]
n8r has joined #river
n8r has quit [Quit: WeeChat 3.1]
<exception> Plain iwd
<ifreund> +1 for iwd
<ifreund> even though it requires dbus, it's much more sane to use than wpa_supplicant
<novakane[m]> iwd is great, connman too
leon-p has joined #river
<leon-p> if you don't mind systemd, then I recommend iwd plus systemd-networkd. That setup has a bit smarter routing than just plain iwd with dhcpd. And is still ten times faster to connect than NetworkManager.
<exception> You can use iwd with its built in resolver right?
<leon-p> you can, but i just use systemd-resolved. Resolving is actually quite a nightmare to get right since so many programs want to do it themselves, so I am happy for one that just takes care of everything for me.
<exception> Ah i either use the default or resolvconf since i do not use systemd
<leon-p> careful: there are a ton of programs that literally just overwrite resolvconf when they wantr
<exception> Yeah i check the file a few times a week
<ifreund> I've been using openresolv with iwd without issues
<ifreund> on void so no systemd of course
yyp has quit [Quit: now it's safe to turn off your computer]
leon-p has quit [Quit: leaving]
leon-p has joined #river
<ifreund> I'm currently questioning whether anyone will ever actually use the ability to set the output title we currently expose
<ifreund> I think we should just set it to `river - OUTPUT_NAME` and be done with it
<novakane[m]> I don't really see any use for this tbh
plumps[m] has joined #river
<leon-p> yeah, it was a gimmick
<ifreund> from a brief glance, I don't see any other wlroots compositor that exposes this as a configuration option
<ifreund> customizing it from the wlroots default seems like a nice touch, but I think I'll stop there
<plumps[m]> Hi :)
<ifreund> welcome!
<leon-p> btw, there now is a WIP PR for zig-shellcomplete to see how well its API works
<ifreund> nice! I'll take a look when I have a minute
<ifreund> leon-p: I've gotten rid of the parameters_changed request in the layout protocol on my branch with the proposed changes. Do you see any reason to keep that?
<ifreund> I don't really see a reason to support layouts that depend on more than what we now expose in the protocol
<leon-p> if we don't want layouts to depend on external parameters, we can get rid of it. It was a nice idea, but I don't actually see a use case
<ifreund> it was required with the river-options approach, but yeah I think we should nuke it for now
<ifreund> we can always add something similar back in with a concrete usecase that we think makes sense to support
<novakane[m]> ifreundI think I'm gonna let you implement damage tracking I'm going mad :p
<ifreund> novakane[m]: no worries, I promise to finally get to it after all the blockers for 0.1.0 are done
<novakane[m]> ifreund nah for real I'd really like to make it but I'm not sur I can without help tbh
waleee-cl has joined #river
snakedye has joined #river
<novakane[m]> what's blocking 0.1.0 btw?
<novakane[m]> the glibc problem upstream iirc and?
<ifreund> the glibc linking problem upstream, which means waiting for zig 0.8.0
<ifreund> plus there's my draft PR that's going to break things again
<ifreund> and after that whatever other smaller breaking changes/polish I think make sense
<novakane[m]> alright
<novakane[m]> is there an ETA for zig?
<ifreund> may 31 is the target release date afaik
<ifreund> who knows, maybe I'll even have time to implement damage tracking before then :D
<novakane[m]> nice thanks
<novakane[m]> well go for it I can't wait for river without freeze :p
snakedye has quit [Quit: Connection closed]
<leon-p> ifreund: any complains about the API of zig-shellcomplete? I am going to work on static completion trees in a moment
<ifreund> leon-p: it seems quite reasonable
<ifreund> I wonder if something more declarative would be feasible though. e.g. https://zigbin.io/3dc9ad
<leon-p> I'll consider it
<ifreund> It's up to you really, my number 1 priority is not having to write/maintain this myself :D
<ifreund> I think I would prefer if rivers definitions were in some other file than river's build.zig though (which would then be imported into the build.zig)
<leon-p> makes sense, probably completions/river.zig and then use @import()
yyp_ has joined #river
yyp has joined #river
yyp has quit [Client Quit]
yyp_ has quit [Remote host closed the connection]
yyp has joined #river
yyp_ has joined #river
yyp_ has quit [Client Quit]
yyp_ has joined #river
yyp_ has quit [Client Quit]
<leon-p> the declarative approach seems nice, but zig apparently does not infer the type when an array literal is passed to a function, so it might be a bit more annoying since the type has to be imported as well...
<yyp> That seems reasonable, no language I know of infers type of the function parameters
<leon-p> zig does in other places though. Consider fn foo(bar: RandomUnion), where you can do foo(.union_member)
<yyp> leon-p: but you still give it a type annotation
<yyp> Oh wait, nevermind
<leon-p> of course, in the function. and zig infers the type at call site
<yyp> Yeah, I didn't think of something like do_thing([]_{a, b, c})
<ifreund> that's not valid zig
<ifreund> this works on master: https://zigbin.io/162573
<ifreund> leon-p: I assume you want a slice not an array?
<leon-p> I honestly don't know what I want here.
<leon-p> I have a predefined type, Option, and I want to pass multiple of those to a function
<ifreund> yeah, slice is what you want. With an array you'd have to put the length in the function signature
<ifreund> I don't think &.{1, 2, 3} works on zig 0.7.1 though by the way
<leon-p> yeah, just noticed
<leon-p> it apparently created a single item pointer on 0.7.1, if I interpret the error correctly
<ifreund> so you'd probably need something like foo(&[_]Option{ .{ .name = "option1" }, .{ .name = "option2" } });
<leon-p> yeah, I just hoped that explicitly stating the type could be avoided
<ifreund> well, it could be if you used anytype :P
<ifreund> then you probably need to iterate at comptime though, and you lose the strictness of the signature
<leon-p> yeah I am after strictness here
<leon-p> anyway, explicitly stating the type works, so I'll just do that for now. Seems like in 0.8 users can just update to &.{} without problem, so I am not concerned about that.
snakedye has joined #river
<snakedye> leon-p Suggestion regarding the layout protocol. "push_view_dimensions" could take an extra argument which would be where the view is inserted in that stack (top or bottom). Something like attach mode.
<yyp> ifreund: I knew that this is not valid Zig, only proposing the idea
<ifreund> snakedye: NACK, the layout protocol is for laying out views not modifying the stack
<snakedye> It doesn't modify the stack, it changes the way river interprets the views
<leon-p> snakedye: it does modify the stack.
<leon-p> unless you propose adding an additional list to keep track of views, which is a NACK as well
<leon-p> also, did we not already had this discussion?
<ifreund> anybody want to watch me delete a bunch of code? I think I might stream again
<snakedye> I also supposed a modify stack protocol is also a NACK
<ifreund> river-control will essentially be that
<ifreund> I definitely want that separated from layouts though
<ifreund> river-control already is that in fact, it just sucks
<snakedye> could I run a river-control command in the middle of sending a layout?
<leon-p> if river-control is still supposed to be atomic, it would be perfect for modifying the stack
<leon-p> snakedye: probably not
<ifreund> you could indeed, this would likely cause the outstanding layout_demand to get preempted by a new one
<leon-p> although I do feel like we are re-inventing X here. first a protocol to move windows around, now a command queue
<ifreund> we'll see how river-control shapes up, it's not at all clear to me how it will work out yet
<ifreund> first things first, time to delete river-options :D
<snakedye> 🥳
<leon-p> it is only right to stream that, considering you added v2 on stream as well :D
<ifreund> yeah :D
<leon-p> how do you record, btw?
<leon-p> s/record/stream/
<ifreund> wlr-obs
<leon-p> huh. I need to try that.
<snakedye> didn't obs merge xdg-desktop-portal?
<ifreund> why would I want another middleman
<leon-p> I thought about giving a small talk about zig-shellcomplete when it's done (since I think its something that other people may like as well) and need a way to stream my slides
<ifreund> also dbus is the worst
<ifreund> talks are always a good idea, go for it!
<yyp> Sadly, I'm not able to watch it live today, but will definietly watch the recording :)
<leon-p> ifreund: your twitch->weechat thing might not be working correctly. there are message in twtich chat but they don't reach you apparently
<yyp> ifreund: looks like the stream doesn't work
<yyp> is it ok right now?
<leon-p> I can watch it, but there seems to be a delay of ~30secs
<yyp> I can't watch it at all though
<leon-p> yeah, now it's dead :D
<yyp> yay, it started working
<leon-p> welcome to Germany, where the internet is mostly bad ("Bambusleitung") and sometimes rarely pretty decent
<yyp> ifreund: how are you doing fuzzy search & open in Kakoune?
<yyp> * ifreund
<yyp> stupid bouncer
<yyp> ifreund: would you mind sharing that script?
<yyp> nice
<yyp> So, river-options is getting replaced by river-control's {get,set}_option?
<yyp> ifreund: weechat is written in C :^)
<yyp> I've seen extensions in Rust and C though
<yyp> ifreund: I mean WeeChat extensions
<yyp> ifreund_: why is main_count u31? That is a bit weird for me
<yyp> mmm, negative window count
yyp has quit [Remote host closed the connection]
yyp has joined #river
yyp has quit [Remote host closed the connection]
ifreund1 has joined #river
ifreund has quit [Ping timeout: 260 seconds]
snakedye has quit [Quit: Connection closed]
ifreund1 is now known as ifreund
ifreund has quit [Quit: WeeChat 3.1]
ifreund has joined #river
leon-p has quit [Quit: leaving]