ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor || https://github.com/riverwm/river || channel logs: https://libera.irclog.whitequark.org/river/
Guest48 has joined #river
eShaev9z_ has joined #river
eShaev9z has quit [Ping timeout: 265 seconds]
dbuckley has quit [Ping timeout: 256 seconds]
Guest48 has quit [Ping timeout: 260 seconds]
angry_vincent has joined #river
angry_vincent has quit [Changing host]
angry_vincent has joined #river
jao has quit [Ping timeout: 255 seconds]
upsala has joined #river
taupiqueur has quit [Ping timeout: 252 seconds]
taupiqueur has joined #river
taupiqueur has quit [Ping timeout: 250 seconds]
taupiqueur has joined #river
taupiqueur has quit [Ping timeout: 264 seconds]
taupiqueur has joined #river
taupiqueur has quit [Ping timeout: 252 seconds]
taupiqueur has joined #river
taupiqueur has quit [Ping timeout: 246 seconds]
taupiqueur has joined #river
<leon-p> ifreund: there may be a slight issue with the recent change w.r.t. tiled state. GTK views transitioning from tiled to float do not update their rendering to reflect the non-tiled state, the other way around works as expected.
<ifreund> leon-p: hmm, seems to work for me. gtk3-demo gains rounded corners and a drop shadow when transitioning from layout to float
<leon-p> hmm... seems like only gtk4 is affected. perhaps a gtk bug then
<ifreund> gtk4 never seems to change for me, maybe it just doesn't render differently in the tiled state
<ifreund> it has rounded corners and drop shadows no matter if the tiled state is set or not
<leon-p> for me it depends on whether the view was first mapped floating or tiled. Round corners and shadow in the first case, until moved to tiling state, none in the second case, even if moved to tiling.
<leon-p> Am on git master, btw
<ifreund> hmm, sounds weird
<ifreund> for me it doesn't seem to matter if they start floating or tiling
<leon-p> which application are you using for testing?
<ifreund> perhaps comparing the WAYLAND_DEBUG=1 logs for the two cases would shed some light
<ifreund> gtk4-demo
<leon-p> paste contains two logs, gtk4 demo mapped tiling and mapped floating
<leon-p> off-topic, but the multi-file paste thing could use a slight UI overhaul, still neat though
<ifreund> cool, I'm currently working on fixing mpv interactive resize which is super funky on master cause it now locks to the aspect ratio
<ifreund> it's nearly perfect now, just gotta fix a single imperfect frame on the transition from layout to interactive resize
<leon-p> oh, nice!
<ifreund> the patch set also entirely eliminates the minor cursor jitter during interactive resize that we have on master branch :)
<leon-p> this release is going to be a massive leap forward
<ifreund> yeah for real, I feel like I've finally developed the skills needed to actually write 100% solutions to these problems rather than the 90-95% solutions we had before :)
<ifreund> man, I wish your wayland debug logs printed array contents, it's so annoying to debug xdg toplevel state otherwise :/
<ifreund> hopefully I can get someone to merge my wayland MR at some point: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/301
<leon-p> seems useful enough, so probably at some point
notzmv has joined #river
<ifreund> you know, I think interactive resize of layouts is possible and perhaps not even that bad with the new transaction system
<ifreund> might try to prototype that this release cycle
<ifreund> just because it would be cool as shit
<leon-p> we could perhaps have a way to communicate cursor movements to the layout and a way for the layout to ack them or something, so that it can bind them to things like changing the main ratio
<leon-p> however anything more than that has the danger of forcing design decissions onto layouts
<leon-p> also there needs to be a way to communicate which view the resize operation of initiated on (at least the index), as layouts may have different areas that can be resized indivdually
Guest48 has joined #river
<Guest48> Hello, I am reaching out as I need some help with installing river on FreeBSD and I would appreciate if anyone could point me to the right direction or give the solution to my problem. Here are some things to know:
<Guest48> Computer info:
<Guest48> - Lenovo Thinkpad T480s
<Guest48> - Intel Core i7 8th Gen
<Guest48> - UHD Graphics 620
<Guest48> - 24 GB RAM
<Guest48> - FreeBSD 13.1-RELEASE
<Guest48> River installed as a binary from the Latest port branch.
<Guest48> river 0.2.4
<Guest48> Error that shows up:
<Guest48> info(wlroots): [wayland] error: XDG_RUNTIME_DIR is invalid or not set in the environment
<Guest48> I followed the Handbook, and since I am I have intel's GPU, I did the following:
<Guest48> # pw groupmod video -m vladimir
<Guest48> # pkg install wayland seatd
<Guest48> - Add to .shrc:
<Guest48> export XDG_RUNTIME_DIR=/var/run/user/`id -u`
<Guest48> Install appropriate graphics drivers:
<Guest48> # pkg install drm-kmod
<Guest48> Lastly:
<Guest48>  # sysrc seatd_enable=”YES”
<Guest48>  # service seatd start
<Guest48>  # river
<Guest48> I am relatively completely new to FreeBSD and unix systems in general. Clearly the issue is with XDG_RUNTIME_DIR
<Guest48> I am not sure what it does and why is my export command not working...
Guest48 is now known as vladimir
dbuckley has joined #river
notzmv has quit [Ping timeout: 246 seconds]
vladimir has quit [Ping timeout: 260 seconds]
Guest48 has joined #river
Guest48 has quit [Ping timeout: 260 seconds]
<angry_vincent> i use river on FreeBSD
<angry_vincent> let me look how set it
<angry_vincent> i set XDG_RUNTIME_DIR in ,bash_profile
<angry_vincent> err, in .bashrc rather https://bpa.st/P3WIM
sparogy has quit [Remote host closed the connection]
vladimir has joined #river
<vladimir> angry_vincent Thank you, I will take a look. I just finished posting the question to Stack Exchange if anyone wants to reference it in the future:
<vladimir> For now, I am sticking to using Bourne shell instead of bash, but it shouldn't be different from what you have.
<vladimir> I see that you are checking if the XDG_RUNTIME_DIR is empty and creating it otherwise.
<angry_vincent> Yes.
<vladimir> That was basically one of my questions. The directory does not exist on my system and I didn't know if I had to create one
<vladimir> I'll create it and try again
<vladimir> Do I need to populate it with anything
<vladimir> And is it okay that I set the path to what the Handbook recommends:
<vladimir> export XDG_RUNTIME_DIR=/var/run/user/`id -u`
<vladimir> I see that you have it in /tmp/`id -u`
<angry_vincent> No, you do not need to populate it
<angry_vincent> in my case, it will be /tmp/1001
<angry_vincent> Notice, that my /tmp is on tmpfs
<vladimir> I saw that part in the handbook regarding the warning about ZFS
<vladimir> The handbook suggests:
<vladimir> In this case, the tmpfs file system is used for /var/run and mounted through the command mount -t tmpfs tmpfs /var/run command and then make this change persist across reboots through /etc/fstab
<vladimir> If I run  mount -t tmpfs tmpfs /var/run
<vladimir> How do I need to format my fstab file
<angry_vincent> i do have my own layout for ZFS datasets, not the one from default install
<vladimir> Is there any function like genfstab on Arch for example
<vladimir> And is it mandatory to format /var/run as tmpfs?
<angry_vincent> no, there is no such things :)
<ifreund> the only requirements of XDG_RUNTIME_DIR is that it exists and is owned by your user with 700 permissions
<vladimir> Thank you both
<vladimir> So what's the purpose of using tmpfs file system for /var/run
jao has joined #river
<vladimir> Again, excuse my 0 knowledge on administration and file systes
<vladimir> systems*
<ifreund> it's more efficient for files that don't need to survive across a reboot
<ifreund> tmpfs is an in-memory filesystem
<vladimir> Okay, so I took a peek at my fstab and I am curious how I would populate it if I do: mount -t tmpfs tmpfs /var/run
<vladimir> ifreund thank you for the clarification
<vladimir> When I list my devices, I see zroot/var/tmp
<vladimir> I get what the mount point would be and FStype
<vladimir> what about Options, Dump, and Pass
<ifreund> I think you're better off asking about that kind of thing in a FreeBSD channel tbh
<vladimir> I unsure, especially when trying to get used to how devices are laid out on FreeBSD
<vladimir> okay thank you.
<vladimir> Makes sense
<vladimir> I will try to get it working by creating the dir and giving it appropriate permissions
<angry_vincent> vladimir: use it for /tmp
<angry_vincent> not /var/tmp
sparogy has joined #river
fitrh has joined #river
sparogy has quit [Remote host closed the connection]
sparogy has joined #river
sparogy has quit [Remote host closed the connection]
sparogy has joined #river
upsala has quit [Remote host closed the connection]
sparogy has quit [Remote host closed the connection]
sparogy has joined #river
vladimir has quit [Quit: Ping timeout (120 seconds)]
fitrh has quit [Quit: fitrh]
linkert has quit [Remote host closed the connection]
janics[m] has joined #river
janics[m] is now known as Janic[m]
Szadek has joined #river
talismanick has joined #river
Szadek has quit [Quit: WeeChat 3.8]
<jacobly> I seem to be getting consistent crashes when toggling outputs
<ifreund> jacobly: have you updated to the latest master? I pushed some fixes for that today
<jacobly> weird I get compile errors, am I still supposed to be using zig 0.10.1?
<jacobly> oh
<jacobly> right submodules
angry_vincent has quit [Remote host closed the connection]
<ifreund> yeah, gotta hate them but I can't use zig's package manager for river yet :/
<ifreund> setting submodule.recurse to true helps a lot though
<ifreund> idk why it isn't the default, probably some gnarly edge case that I never hit in practice
<jacobly> I just have an alias
<jacobly> some repos are recursive and will clone submodules until you run out of disk space lol
<ifreund> lmao
<ifreund> guess that's the "gnarly edge case"
<jacobly> now instead of crashing it hangs
<jacobly> no longer able to connect
<ifreund> jacobly: hmm, are you able to get a debug log of that happening?
<ifreund> Or what step should I take to try and reproduce?
<jacobly> it happens any time I turn an output on
<ifreund> do you have more than one output?
<jacobly> yes, 2
<jacobly> wait there is a mouse
<ifreund> I've seen some weirdness around output configuration being applied that wasn't there before the scene graph patches
<ifreund> it might be the case that turning the output off/on lands you in a state where the outputs are overlapping or something which can definitely seem like a hang
<jacobly> yes the two outputs are both at 0,0
<jacobly> I think this is the right part of the log https://gist.github.com/jacobly0/de41dd351697676da23a633caf869809
Szadek has joined #river
<jacobly> doesn't look like it's having a great time, at least
<jacobly> the repro was sleep 10 seconds, turn DP-2 off, sleep 10 seconds, turn DP-2 on
<jacobly> at which point the cursor works and both screens are overlapping but nothing can connect to the wayland server anymore
<jacobly> I also attached a debugger but it was just sitting in poll and I wasn't sure what to look for
<ifreund> thanks, I managed to reproduce it here
<jacobly> also happened when toggling both monitors, but one seemed like a simpler repro
talismanick has quit [Ping timeout: 246 seconds]
<ifreund> jacobly: I think I understand the issue but I don't know what the right way to fix it is. It's pretty late here though, I'll have another look tomorrow
talismanick has joined #river
talismanick has quit [Remote host closed the connection]
taupiqueur has quit [Read error: Connection reset by peer]
taupiqueur has joined #river
Gozenka has joined #river
Gozenka has quit [Client Quit]