05:05 <NickH> vipulogmx: I made a public repo with river for bullseye. I *think* I included all the required dependencies. I'd be interested to see if it works for you.

05:06 <NickH> See https://www.asahi-net.or.jp/~kp9n-hstn/

05:07 <NickH> All my bullseye machines have a bunch of additonal backported packages so there is a chance one or more of the depedencies is missing. So if you have problems let me know and I'll try to fix them.

05:22 <NickH> I also have up to date packages for things like fuzzel and waybar if you're interested.

06:15 <NickH> I just checked it on a clean bullseye install on a vm. Seems to work.

16:33 <Guest9147> Hi, just wanted ask if river init file can be split into multiple files

16:34 <Guest9147> I tried using riverctl spawn "/path/to/other_file.sh" but it does not pick it up.

16:36 <tiosgz`> is the file executable? also, you can just do `/path/to/other_file.sh` if it doesn't do something like `exec` that would "block" it

16:37 <tiosgz`> (without the ``)

16:37 <Guest9147> It is executable yes

16:38 <tiosgz`> can you run it in a terminal w/o errors?

16:38 <Guest9147> I just uh want to split up the config into parts - launchers in a separate file, keyboard and mice configuration in its own file, and layout etc. in its own file

16:39 <novakane> just use `source /path/to/file`

16:39 <novakane> that should do it

16:39 <Guest9147> Well it was a simple file with only one line `riverctl map normal Super w close`

16:40 <tiosgz`> without a #! ? (`source` should work w/o it though, yea)

16:41 <Guest9147> I'll try that, just a minute

20:41 <edrex[m]> Does River run nested under X11 similar to how it runs nested under wayland? Someone is reporting that happening on another channel, and I don't have X stuff.

20:43 <tiosgz`> yes, it should

20:57 <ifreund> assuming wlroots was build with the X11 backend enabled, yes

21:12 <edrex[m]> thx

21:54 <edrex[m]> Open to a patch to add a wayland-sessions .desktop file ala https://github.com/swaywm/sway/blob/master/sway.desktop?

21:55 <edrex[m]> oh there is one, it's just in contrib

21:56 <edrex[m]> sway's meson.build puts it in the right spot, otherwise packagers have to. Open to a patch to have the build put it in the right spot?

22:01 <ifreund> edrex[m]: nope, no offical support for desktop files as it's not standardized

22:02 <ifreund> well, not standardize for use in this way I mean

22:09 <edrex[m]> k, figured. Y'all purists in here :P

22:10 <edrex[m]> probably going to patch the nixpkgs river to copy it

22:34 <ifreund> edrex[m]: yeah I'm not opposed to distros including it in their packaging

22:34 <ifreund> I just don't think GDM deciding to use desktop files in this way means that every one should try and support it

22:36 <ifreund> starting river is officially as simple as running the river command, I don't see why it needs to be more complex than that

22:40 <edrex[m]> they're just a registration mechanism for "shelley" runnables, so users don't have to hand-configure whatever they use to start sessions.

22:40 <edrex[m]> could be a lot simpler.

22:41 <leon-p> pretty sure it's about discoverability. It allows the DM to know which desktops are available without needing a hardcoded list, so it can have a nice "choose your desktop" menu.

22:41 <edrex[m]> ⬆

22:41 <edrex[m]> wow that arrow came out big

22:42 <leon-p> Too me it makes sense to re-use them for this use case, as it's pretty much the same as when they are used for GUI programs

22:43 <leon-p> and for icons too because we don't have fat binaries, although that is less important for desktops.

22:44 <leon-p> I guess you could also have a directory with symlinks to binaries, but that would mean no description in the menu, because no fat binaries

23:06 <ifreund> I guess that does make sense, still would like to see it actually standardized though

23:07 <ifreund> I'm pretty sure a ton of what's allowed by the .desktop spec makes no sense in this context as well

23:14 <leon-p> probably. But it's to be expected, considering the possibility of bad input / config is ignored elsewhere in the gnome stack as well. I mean, you can make gnome shell and GDM literally crash by manually setting bad values in gsettings or with a faulty icon theme.

23:25 <edrex[m]> Practically, it would remove a gotcha for packaging. It would be good if there were an alternative mechanism. any thoughts on that kennylevinsen?

23:25 <edrex[m]> Opened https://github.com/NixOS/nixpkgs/pull/163391

23:30 <kennylevinsen> idk. In gtkgreet there just 1 file, each line is a command line that will be an option in the drop down - which can also be edited if you want to do something different. Only thing I hear people complain about is lacking "alias" so they can use arbitrary names.

23:32 <edrex[m]> Amusingly, since NixOS doesn't follow FHS, the user still has to manually add the package to the list of sessionPackages for display managers

23:33 <edrex[m]> ¯\_(ツ)_/¯

23:34 <kennylevinsen> greetd itself only cares about the final command line, and the greeter policy has so far been "whatever works for your users to get that command line". Something slightly unified wouldn't hurt, but I feel like it would devolve into people wanting it to support specifying alternate languages, icon types that are everything from BMP to MPV, environment info, and whatnot...

23:34 <edrex[m]> oh, seatd itself doesn't know about sessions, that's on the greeters?

23:34 <kennylevinsen> *greetd I assume but yeah

23:34 <edrex[m]> oops yes

23:35 <edrex[m]> they rhythm and it confuses me!

23:36 <kennylevinsen> greetd is sent a username and a command you want to run, and then asks whatever questions are needed for authentication. The command could be anything at all. A graphical shell, a textual shell, even just a one-off command. greetd doesn't know and doesn't care.

23:36 <kennylevinsen> It just stuffs it into /bin/sh -c and calls it a day

23:40 <kennylevinsen> man 7 greetd-ipc or https://docs.rs/greetd_ipc/latest/greetd_ipc/enum.Request.html for more info on what the greetd API looks like