06:21 <leon-p> I think we should eventually make use of more powerful matching criteria for out filters than just the app-id. Trying to get programs like zoom to behave nicely is otherwise impossible since all of the thousands of windows it spawns for whatever unholy reason all have the same app-id. At least also matching by title should be available.

07:09 <leon-p> regarding issue#263, I think it might be a problem that we hardcode `/bin/sh` for spawn commands. Maybe we should use $SHELL (is that even standard?) or have it somehow configurable (`riverctl set-option shell /whatever/shell`).

07:09 <emersion> it's expected that all windows of a given app share the same app-id

07:10 <leon-p> yeah, the "for whatever unholy reason" was more aimed at zoom spawning multiple windows. But that is exactly why we need better ways of matching windows for our filters.

07:13 <emersion> ah :)

07:15 <novakane[m]> leon-p: maybe using something like /usr/bin/env sh for spawn instead if it possible

08:12 <ifreund> leon-p: I was under the impression that /bin/sh was posix

08:13 <emersion> it's… complicated

08:13 <emersion> /bin/sh is not strictly POSIX, but nor is /usr/bin/env

08:13 <emersion> /bin/sh is likely more widely recognized

08:14 <leon-p> the issue is about nix, which is not exactly known to be posix complient

08:14 <ifreund> leon-p: well sway does the /bin/sh thing as well iirc and works according to them

08:14 <leon-p> but I was wrong anyway, that can not be the issue, as the user reports their exit keybinds work, which implies init was executed which river does with /bin/sh as well

08:14 <ifreund> I still suspect user-error/a config issue and haven't really looked closely

08:15 <emersion> i wonder if performing a $PATH search for `env` (execvp?) with `sh` as arg would be more portable… at the cost of a double $PATH search

08:15 <emersion> yeah we just do /bin/sh in sway

08:15 <ifreund> seems very strange to me that POSIX does not specify a portable way to find/run its portable spec'd out shell

08:15 <emersion> hm, i suppose you can just execvp `sh`

08:16 <emersion> but yeah it doesn't help with script shebangs

08:23 <yyp> huh, "Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh"

08:27 <yyp> emersion: why look up env? You can just find sh and then spawn ["sh", "-c", command]

08:28 <emersion> yeah i mean use execp instead of exec

08:28 <emersion> ah yeah, env is useless here

08:28 <emersion> realized it later

08:28 <emersion> fixing sway now

08:29 <emersion> fprintf(tmp, "#!/bin/sh\nrm %s\n%s", fname, command);

08:29 <emersion> wtf is this doing

08:30 <emersion> oh well

08:31 <leon-p> ifreund: could you quickly look over the last commit I pushed to the river-layout PR? I can't exactly remember how that part of river exactly works, so I am not 100% confident about it. The idea of the commit is to avoid rearranging when leaving fullscreen and it also fixes #243.

08:48 <yyp> Who is the maintainer of river in AUR?

08:48 <yyp> *river-git

08:50 <leon-p> yyp: paru -Si river-git | grep -i maintainer => Maintainer: daurnimator

08:51 <yyp> They probably need to update it to use wlroots-git as wlroots 0.13.x is not in arch repos yet (or is it?)

08:52 <emersion> not yet

08:52 <emersion> blocked on a river release

08:52 <emersion> … which should happen today!

08:54 <yyp> I would like to add support for multiple keyboard layouts before that though

08:54 <yyp> *before the release

08:54 <emersion> er

08:54 <emersion> i mena cage release

08:54 <emersion> mean*

08:54 <emersion> sorry

08:55 <yyp> Yeah, cage broke on wlroots 0.13

08:57 <leon-p> yyp: it's unlikely that any kind of inputt config will be in the 0.1.0 release. The plan is that river will not do that itself but there to be some sort of protocol extension to allow clients to configure inputs and seats, similar to output configuration

08:57 <leon-p> I wanted to work on that protocol for quite some time but never had enough motivation tbh

08:58 <emersion> interesting

08:59 <emersion> i was kind of assuming that input configure was more "static" than output configuration

08:59 <emersion> configuration*

08:59 <yyp> ^^

08:59 <emersion> but i guess if you want complex matching rules it would make sense

08:59 <emersion> i wonder if there are more use-cases

09:01 <leon-p> main idea was that we just don't want that code in river ^w^w^w^w^w^w^w want to standardize the protocol so that input configuration becoms compositor-agnostic similar to output configuration. But i am not sure how much hope there is for that to ever happen.

09:01 <yyp> Having complex matching rules will be probably very rare, for most use-cases defining multiple layouts and switch via grp:* XKB options would be enough

09:06 <yyp> Having an input management protocol might be nice but I can't think of a read use-case that it will solve

09:07 <yyp> *real

09:07 <leon-p> yyp: there are two use cases in my earlier message: 1) keep all of that stuff out of rivers configuration, which lets us avoid adding lots of complexity and 2) have input configuration compositor agnostic. Configure once and use in every compositor.

09:11 <yyp> fair enough, but such a protocol would for a long block people who write in multiple languages (me) from using river. I think it makes sense to make a draft support (maybe I'll just leave it in a fork) and when the protocol is done, glue it there

09:13 <leon-p> is using a more international keyboard not an option for you? with a compose key you can get quite far

09:14 <yyp> I haven't seen any

09:15 <yyp> Though I can run a nested river instance with XKB_DEFAULT_LAYOUT=ru or something and use other languages, that might be an option

09:15 <yyp> ... but it seems pretty hacky

09:17 <leon-p> ru? Russian? so cyrillic? Yeah then I understand. I was thinking more about extended latin alphabets.

09:17 <emersion> XKB_DEFAULT_LAYOUT supports comma-separated layouts

09:17 <yyp> emersion: no

09:17 <emersion> yes?

09:18 <yyp> river crashes when doing so

09:18 <leon-p> yyp: then open an issue on github please

09:18 <emersion> it's supposed to

09:18 <emersion> if it doesn't, it's a bug

09:18 <yyp> https://github.com/xkbcommon/libxkbcommon/blob/21e640fbc7ec2e53244e4e531ae7c32f249b023f/src/context-priv.c#L139

09:23 <yyp> err, it doesn't crash, but this is what happens: https://0x0.st/-Aqx.mp4

09:24 <yyp> keyboard input just stops working

09:26 <novakane[m]> hmm I tried with XKBDEFAULTLAYOUT="fr,us" and it worked

09:26 <yyp> weird

09:26 <novakane[m]> XKBDEFAULTLAYOUT*

09:27 <novakane[m]> bad correction :/

09:27 <novakane[m]> even "fr,ru" worked

09:28 <yyp> Ok, I switched to use "us,ru" instead but now I can't switch the layout despite that grp:alt_shift_toggle is set

09:28 <emersion> is it eaten by the outer compositor maybe? could happen if grp:alt_shift_toggle is set there too

09:29 <emersion> (even if there's just one layout)

09:29 <yyp> alright, let me check

09:31 <yyp> That did in fact work

09:31 <leon-p> nice

09:32 <yyp> I've closed #254

09:33 <emersion> error reporting could be improved maybe

09:33 <leon-p> emersion: pretty sure thats our motto

09:33 <emersion> there's some setup to do to get libxkbcommon logs, maybe? i don't remember

09:33 <emersion> :)

09:36 <yyp> I think that support for multiple layouts should be documented somewhere

09:38 <leon-p> What exactly do you mean? That you can run multiple layouts generators at once? That a layout generator can advertise multiple layout objects? That the layout generated can depend on the focused tags? Or what?

09:38 <yyp> *multiple keyboard layouts

09:39 <leon-p> oh. My mind is still wired to associate the word "layout" with view dimensions and positions :D

09:40 <novakane[m]> damn you are traumatized by your PR :P

09:43 <leon-p> not by the PR, more by the amount of times I had to explain the concept :D

09:44 <leon-p> although to be fair it is kinda abstract and could be explained a bit better in the official docs

09:45 <novakane[m]> haha yeah I get it

09:45 <novakane[m]> did you finish your article on this btw?

09:46 <leon-p> not yet. But i'll be on a three hour train drive today, maybe I'll do it then

09:48 <novakane[m]> alright, well the day you finish it, repost the link here please

09:49 <leon-p> novakane[m]: It'll be on leon_plickat.srht.site. I have an RSS feed :D It will be the first actual technical article on my blog. I started it to write about technical stuff and then got side-tracked by headphone things for three articles, heh

09:52 <novakane[m]> leon-p: alright I subscribed to the rss, you have the privilege to be in the same folder that emersion blog :P

09:52 <novakane[m]> I didn't know sourcehut could do this

09:53 <leon-p> novakane[m]: sourcehut sites are a new features. Quite nice.

09:55 <leon-p> anyway, I have train to catch. bye

14:46 <novakane[m]> I can't understand issue #263, why spawn would fail

14:47 <novakane[m]> that's weird