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>
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