<XeroOl>
This is definitely not fun. I was hoping to be able to write a quick lua script but connecting to wayland involves either adding dependencies, or a ton of C ffi code
<XeroOl>
it seems like my $WAYLAND_DISPLAY environment variable isn't set, so it can't find a wayland display
<XeroOl>
it seems like I am unable to swap out layout generators at runtime at all
<XeroOl>
rivertile is telling me that its unable to connect to a Wayland server
<NickH>
Note that my config has quite a bit of non-trivial stuff to make the layout switching work with keybindings
<NickH>
In practice you just need to run "riverctl default-layout somelayoutgen" and make sure "somelayoutgen" is running.
<NickH>
What what distro are you running and how are you starting river?
elshize has quit [Ping timeout: 265 seconds]
fitrh has quit [Quit: fitrh]
dbuckley has quit [Ping timeout: 260 seconds]
<XeroOl>
arch linux with the river aur package
<XeroOl>
I'm probably starting it incorrectly, but here's how it's done
<XeroOl>
zsh is my login shell; in .zshrc, I have `if [ -z $DISPLAY ] && [ $(tty) = /dev/tty1 ]; then exec river; fi` at the top
<XeroOl>
so, if I sign in on tty1, it should boot into river
<XeroOl>
it seems like that is a terrible way to boot into river, as it leaves $WAYLAND_DISPLAY unset somehow
<XeroOl>
I've replaced `exec river` with `river; exit` and it is behaving sanely now
<XeroOl>
my plan is to make a layout program that accepts a script, and then communicates with that script over stdin/stdout
<XeroOl>
you could run the layout program `layout-runner python my_cool_layout.py`, and then layout-runner does all the wayland protocol stuff, so that my_cool_script.py only needs to communicate over stdin/stdout, and doesn't need to link to libwayland-client.so
StopNGo has quit [Ping timeout: 260 seconds]
jao has quit [Ping timeout: 265 seconds]
peregrinator has joined #river
hryx has quit [Ping timeout: 264 seconds]
peregrinator has quit [Read error: Connection reset by peer]
mannerism has quit [Remote host closed the connection]
mannerism has joined #river
elshize has joined #river
peregrinator has joined #river
ayushnix has joined #river
peregrinator has quit [Read error: Connection reset by peer]
<leon-p>
if you have any specific questions, then I can also help
<leon-p>
FWIW layouts used to be simple oneshot programs that just dumped window coordinates and sizes to stdout and then exited. We moved to the current model to allow for more complex features, like non-standard layout variables and storing those variables per tag.
peregrinator has quit [Ping timeout: 255 seconds]
peregrinator1 has quit [Ping timeout: 255 seconds]
peregrinator has joined #river
ayushnix has quit [Changing host]
ayushnix has joined #river
aryak has quit [Quit: ZNC 1.9.x-git-192-fecdd989 - https://znc.in]
aryak_ has quit [Remote host closed the connection]
aryak has joined #river
questionable_ole has joined #river
elshize has quit [Ping timeout: 260 seconds]
StopNGo has joined #river
<XeroOl>
leon-p: I'm going go try to keep the simplicity of stdin/stdout, but allow the script to stick around instead of being one-shot like before.
<leon-p>
eh, at that point stdin/stdout are not any more simple than just connecting to the Wayland socket
<XeroOl>
stdin/stdout is builtin to everything, wayland requires many many ffi calls to C, and a dependency on libwayland-client
<leon-p>
for long-running processes such as you plan, you're layouts will need to have an event-loop and implement the (maybe informal but still present) protocol your bridge uses.
<XeroOl>
Yes that's true
<XeroOl>
I'm hoping that will just involve a loop that does blocking read on stdin
<leon-p>
well, Wayland is async, so you'll need to take care when translating that to a protocol you can dump onto a blocking consumer
peregrinator has quit [Remote host closed the connection]
peregrinator has joined #river
<XeroOl>
of course
ayushnix has quit [Ping timeout: 260 seconds]
<leon-p>
however if you merely want to have a "give a layout now" request and maybe a "here is a user-command" one, it should be fine
<XeroOl>
that's the plan
peregrinator has quit [Client Quit]
<XeroOl>
I expect layout events are infrequent enough that it shouldn't hurt to add a bit of blocking
<XeroOl>
especially if the actual layout code is in python/ruby/janet/<insert slow scripting language here>
<leon-p>
the average Wayland client is usally a poll() based and single-threaded, therefore also effectively blocking. As long as you make sure no input is discarded it should work
<XeroOl>
:)
<leon-p>
you proabably also want to know about rivers internal layout deadline: if you take to long to provide a layout, river will ignore your client and switch to all-floating until the next layout demand
<XeroOl>
do you know what that timeout is?
<leon-p>
100ms I think
<leon-p>
so make sure you spin up any interpreters before the first layout demand comes in
<XeroOl>
That makes sense
<XeroOl>
Okay, thank you for your advice
<XeroOl>
So far I have gutted rivertile to take out all of the layout logic and keep the wayland client part
<XeroOl>
now I just need to make it spawn a process, use a lock, and use some super basic text protocol
jao has joined #river
eShaev9z has joined #river
Sora has joined #river
<Sora>
Hello, not sure whether this is right place to ask for some minor support. Essentially i try to swap from xorg to wayland for some sort of personal feasability study. I have 2 issues which are the following: 1. Discord doesn't start. Xwayland is enabled and i made sure (by logging) that the xserver is actually running (which it is) no idea why, but
<Sora>
i also don't get any errors from discord via stdout / stderr (starting it from the terminal)
<Sora>
Funnily enough, i also try using dmenu (via xwayland) which works, but there is another issue: focus is always lost on launch, it doesn't close via ESC (i assume some setting has to be made?) and it also doesn't launch on the currently active cursor monitor (i use a triplet-monitor setup).
<Sora>
For debugging purposes: i am on nixos and if my issues require a view into my config, please let me know.
<Sora>
Thanks already. :)
<leon-p>
for the dmenu issues I recommend just using a Wayland native replacement, like fuzzel
<Sora>
depending on what is meant with correctly, i added it to my pkgs, rebuild nix and could use it then.
<Sora>
obviously, i also adjusted the spawn from dmenu_run -> dmenu-wl_run
<leon-p>
there should not be any focusing problems with a wayland native application, leading me to believe that you accidentally still used the X11 dmenu
<Sora>
ok so i noticed 1 thing: i just always spawn on the exact same monitor all the time, that may be why the focus is lost
<leon-p>
yeah, just focus the monitor it's on
<Sora>
but that doesn't solve the issue i have, does it? which is that the expected behaviour would be, that it spawns on the focused monitor.
<Sora>
at least, that's how i would expect it to behave
<leon-p>
well, that's dmenu-waylands fault, not rivers
<leon-p>
just looked at the code and it explicitly requests to always be on the first output
<Sora>
lemme see if i can figure more out about this behaviour. brb
<leon-p>
there are other dmenu alternatives for wayland though, just use something else