07:18 <leon-p> heh, #609 is lovely example for the great and timeless design of X...

10:30 <mizzunet> hi

10:32 <mizzunet> I want Control+Space to play-pause media and notify the action

10:32 <mizzunet> For that, I tried,

10:32 <mizzunet> riverctl map normal Control Space spawn "playerctl play-pause && notify-send -u low $(playerctl status)"

10:32 <mizzunet> But the notification alway sbeing Paused

10:32 <mizzunet> *always

10:34 <mizzunet> Running playerctl play-pause && notify-send -u low $(playerctl status) manually works as expected

10:35 <tiosgz> Missu: s/"/'/g

10:36 <mizzunet> tiosgz: That works. Thanks (:

10:46 <tiosgz> can a layout generator explicitly (without timing out) revert to floating? (the river_layout_v3 is needed to get user_commands)

14:35 <ifreund> we should probably rename XwaylandUnmanaged to XwaylandOverrideRedirect

14:49 <tiosgz> ifreund: would you please take a look at / comment on #611? (in the end i decided i'll remove that FIXME coz it would be too much additional code)

17:09 <ifreund> tiosgz: gave it a review pass just now, thanks for working on that!

17:10 <ifreund> what was the FIXME about by the way?

17:22 <Shinyzenith[m]> <ifreund> "we should probably rename..." <- I second this, while writing the dmenu patch it has my confused af

17:34 <leon-p> +1 for renaming

17:39 <tiosgz> ifreund: thanks! the FIXME was that Set.subtract only accepts a same-capacity set, but with current usage it doesn't matter

17:40 <ifreund> ah, yeah YAGNI

21:43 <elshize> ifreund: I just read your latest blog post, and I got a question regarding rust/zig part. you mention you pulled many deps in rust; why is that? is it because zig has a broader standard lib and you didn't need those?

21:46 <pmnw> Does river require setting any wayland-related env variables? Asking because I haven't found this information in the manual.

21:48 <Shinyzenith[m]> elshize: Afaik wayland rs simply has more dependencies in its cargo toml

21:48 <Shinyzenith[m]> Where as in zig, you just link with the system library and that's about it

21:51 <elshize> Shinyzenith[m]: right, but seems like both link to the same system libs, but additionally there are almost 50 cargo deps (total, not direct, I understand). seems like it must be either something that's missing in rust stdlib but is present in zig, or else is directly implemented in the zig version... unless I'm missing something important here..

21:53 <pmnw> IIRC, the update article said something about lots of abstraction in Rust bloating the libs.

21:54 <Shinyzenith[m]> Some of the deps that I see in the cargo toml doesn't look like functions missing from stdlib

21:54 <Shinyzenith[m]> Maybe they just wanted better wrappers over them? Such as memoffset, I believe stdlib already had similar functions.

21:54 <Shinyzenith[m]> Then they are also downloading the entire libc crate whereas in zig we just need to call exe.LinkLibC()

21:55 <Shinyzenith[m]> Little things like this add up where as the zig version is purely stdlib of zig, zig-wayland , zig xkbcommon, and pam

21:56 <elshize> say, clap -- how is this implemented in zig version? this type of thing is what I'm wondering

21:56 <Shinyzenith[m]> I honestly have no idea but I'd start by looking at the entry file, that's usually where flags are parsed. But why interest in that? Flag parsing in a minute part of the app

21:59 <elshize> I'm just trying to understand the point: "cargo pulls many deps". it pulls many deps for clap, it's a very heavy dependency. but if you roll your own simple cli parser, then you don't use clap, and you don't pull as many deps.

22:02 <elshize> similarly, clap could implement everything without any deps. it just seems to me this is not related to lang or cargo, but rather that projects use them. unless I'm missing the point, that's why I wanted to ask the questions ;)

22:05 <elshize> the only reason I could come up with why one could use less third-party code is if the language implements the functionality itself (that, and of course implementing from scratch)

22:12 <ifreund> elshize: I think it mostly comes down to the fact that everything takes an order of magnitude less effort to implement in zig :P

22:13 <ifreund> for argument parsing I just have this < 100 loc file I use for all my projects: https://github.com/ifreund/waylock/blob/master/src/flags.zig

22:14 <ifreund> It's more manual than clap for sure, no autogenerated help and whatnot, but it's all I really need for the software I write

22:16 <ifreund> "everything takes an order of magnitude less effort to implement in zig" is tounge in cheek if that wasn't clear, I think the real differences are largely cultural

22:16 <elshize> ifreund: ok, thanks

22:17 <elshize> again, not familiar with zig that much, so can't comment on which one takes more effort ;)

22:17 <ifreund> I do believe that Rust's vastly higher complexity and encouragement of abstraction has an effect on the culture

22:17 <elshize> but I do agree about the cultural aspect.

22:18 <elshize> I suppose it's easy to use other crates, and that can lead to that...

22:19 <ifreund> The alternative to using a crate is implementing it yourself, which is a lot higher friction in rust than in zig in my experience

22:20 <ifreund> part of that could be that I wouldn't consider myself as having mastered rust despite having put quite a lot of time into it

22:20 <elshize> which kind of boils down to "rust is more complex than zig"

22:20 <ifreund> my zig skills outpaced my rust skills in something like a week

22:22 <elshize> tbf, I think this dependency problem is not unique to rust; anything like, say, nodejs or python, leads to similar culture, I think

22:22 <elshize> and I wouldn't say python is that complex.

22:23 <ifreund> fair enough, maybe it is really just how easy the tooling makes it to pull in massive dependency changes

22:23 <ifreund> my impression of the go ecosystem from afar is that this issue isn't as extreem there

22:23 <elshize> but complexity, together with ease of pulling deps, definitely makes it more so

22:23 <ifreund> plus marketing of "zero cost abstraction"

22:24 <elshize> right, I think it's all of the above :)

22:25 <elshize> as far as the size goes (or compile times for that matter) I'm certain it's the high level of abstraction

22:26 <Shinyzenith[m]> Imo I prefer rust when I simply want a PoC fast as smithay client toolkit does a lot of things for me via helpful wrappers and I rewrite in zig for more fine grained control. Not saying you don't have it in rust, it's just more explicit in zig as per my experience

22:28 <elshize> how much is zig changing? is it far from 1.0?

22:29 <Shinyzenith[m]> Andrew recently spoke about this in the Milan convention. He expects it to be around 2025 if my memory serves me right.

22:30 <ifreund> elshize: The language is fairly stable aside from a few more experimental edge features like async and SIMD vectors. The standard library will see massively breaking changes before 1.0 though

22:34 <elshize> got it. it's definitely on my list, just need to secure some free time ;)

22:35 <ifreund> do note that documentation is not great yet, don't hesitate to ask questions in #zig or elsewhere if you run into issues :)

22:49 <elshize> thanks, will have that in mind