<Nosrep>
anyone else had problems with imv -f? it just messes up the focus (river's borders shows nothing as being focused and i can't move around with keybinds) and never actually appears
muirrum has joined #river
jao has quit [Ping timeout: 276 seconds]
fitrh has joined #river
eShaev9z has joined #river
eShaev9z_ has quit [Ping timeout: 260 seconds]
<waleee>
the imv developer had less time to spend on it these days according to https://todo.sr.ht/~exec64/imv/43 so I imagine that some bugs might be accumulating
<Gozenka>
The Chromium closing issue seems to be gone with the last commit.
<Gozenka>
I could not reproduce it with ebfa892. I went back to f072d19 and it happpened again.
<Gozenka>
(y)
fitrh has quit [Read error: Connection reset by peer]
fitrh has joined #river
Gozenka has quit [Quit: Client closed]
muirrum has quit [Ping timeout: 276 seconds]
muirrum has joined #river
muirrum has quit [Ping timeout: 276 seconds]
dbuckley has quit [Ping timeout: 255 seconds]
muirrum has joined #river
waleee has quit [Ping timeout: 268 seconds]
muirrum has quit [Ping timeout: 255 seconds]
muirrum has joined #river
angry_vincent has joined #river
angry_vincent has quit [Changing host]
angry_vincent has joined #river
Szadek has quit [Quit: WeeChat 3.8]
fitrh has quit [Quit: fitrh]
vaivis has quit [Ping timeout: 268 seconds]
vaivis has joined #river
<ifreund>
Nosrep: imv 4.4.0 seems to work properly for me on master branch with the -f option
<ifreund>
in general though imv is one of the more buggy wayland clients I've encountered
Guest6994 has joined #river
Guest6994 has quit [Client Quit]
Guest35 has joined #river
Han has quit [Remote host closed the connection]
fitrh has joined #river
Guest35 has quit [Quit: Client closed]
fitrh has quit [Read error: Connection reset by peer]
fitrh has joined #river
upsala has joined #river
fitrh has quit [Quit: fitrh]
<upsala>
If I'd like to understand how river code actually works and understand what is happening in the code, what would be a good place to start? Would reading about wayland be a the best idea and then get familiar with zig itself?
<ifreund>
upsala: hmm, I'm not entirely sure where the best place to start would be. Are you already familiar with C?
<ifreund>
if so the tinywl.c example in the wlroots repo would be worth checking out, it has lots of comments to explain what is happening
<upsala>
I coded some C but saying I'm "famliar" with it would be a vast overstatement I think
<ifreund>
ok, the reading the comments in tinywl.c may be useful nonetheless
<upsala>
Ok I'll take a look at that thanks
<ifreund>
zig and C are really quite similar in many ways, zig just drops a lot of legacy baggage while adding flexibility and type safety
<upsala>
I started to read the ziglearn stuff and it seems pretty easy to understand so far
<ifreund>
yeah, that's pretty much how I ended up writing this in zig
<ifreund>
just went "I'll give it a try and see how it works" and river is what happend
<ifreund>
you can see the first zig code I ever wrote if you go back to the beginning of the git history
<ifreund>
anyhow, more general information on the architecture of wayland will also be quite useful for understanding the bigger picture
<tleydxdy[m]>
so why is tiled state tied to if there's borders? in XdgToplevel.zig:120
<tleydxdy[m]>
floating views can also have borders right?
waleee has quit [Ping timeout: 276 seconds]
Misthios has quit [Quit: Misthios]
Misthios has joined #river
Misthios has quit [Client Quit]
Misthios has joined #river
vaivis has joined #river
<rodrgz>
ifreund: I was watching your presentation on zig SHOWTIME, you said that improving battery consumption would be a good feature, do you have any idea what can be done to improve this?
<rodrgz>
btw, congratulations on the presentation
Gozenka has joined #river
<Gozenka>
I also watched Isaac's presentation while I was looking for Wayland alternatives to dwm. I liked his demeanor and approach to developing River, so I decided to try it out for my Wayland transition. :)
<Gozenka>
tleydxdy[m] ifreund Personally, the only things I seem to lack on base River are: smartborders, pertag, fullscreen-monocle (ability to cycle between windows while in fullscreen, rather than the regular monocle mode).
<Gozenka>
Otherwise I love River, it is really performant, feels quicker with less CPU and RAM usage than my well-loved dwm setup. The riverctl config method and the option for independent layout generators seem to be an awesome way to enable independent customization and is probably good for the future life of the project too.
<Gozenka>
It uses less resources and "feels" better than Hyprland with all eye candy removed.
<tleydxdy[m]>
there used to be a lot more patches but they've mostly gone upstream, yay
<tleydxdy[m]>
the monocle there is per tag, btw
hspak3 has joined #river
hspak has quit [Read error: Connection reset by peer]
hspak3 is now known as hspak
<angry_vincent>
i somehow also in favor of having monocle in upstream river but not too upset it will not be there. life is too short to try all forks
<Gozenka>
nice. I know nothing about zig and Wayland code, but it seems like a very simple and straightforward code to add Monocle mode.
<Gozenka>
I would prefer it to be fullscreen rather than monocle though, I will try to just implement that via combo keymaps.
<tleydxdy[m]>
yeah, the issue with monocle used to be that it's not possible to implement correctly with only layout generators, now with the scene graphs, it seems to be okay again
<tleydxdy[m]>
so not having it upstream is not a big loss
<tleydxdy[m]>
you are expected to swap out the layout generator for ones you like anyways
<ifreund>
Yeah, I still have plans to push even more of this window management policy out to the layout generator, probably making it more like a simple window manager than just a layout generator
<ifreund>
thanks for the kind words Gozenka, glad river is useful to you!
<angry_vincent>
what would scene graph allow? is it something new in window management
<tleydxdy[m]>
I haven't looked that closely yet, but the buggy monocle behavior is gone, probably because the update implemented a focus stack?
<ifreund>
it almost certainly has more to do with the new transaction system architecture than the scene graph itself
<tleydxdy[m]>
ifreund I'm wondering why is XdgToplevel.zig:120 check the .borders rather than .float for xdg tiled?
<ifreund>
I just used the occasion of switching to the scene graph to rewrite rivers core data structures and the same time while I had all the code fresh
<ifreund>
tleydxdy[m]: its a holdover from rivers early days, a hack to make gtk windows look better with SSD
<ifreund>
I'm planning on changing that this release cycle
<tleydxdy[m]>
ah, I see. it was causing trouble for me with mpv
upsala has quit [Quit: Client closed]
notzmv has quit [Ping timeout: 248 seconds]
Misthios has quit [Remote host closed the connection]
Misthios has joined #river
Misthios has quit [Remote host closed the connection]
Misthios has joined #river
Misthios has quit [Client Quit]
Misthios has joined #river
Misthios has quit [Client Quit]
Misthios has joined #river
Gozenka has quit [Ping timeout: 260 seconds]
waleee has joined #river
Misthios has quit [Quit: Misthios]
Misthios has joined #river
qyliss_ is now known as qyliss
angry_vincent has quit [Remote host closed the connection]
taupiqueur1 has quit [Quit: WeeChat 3.8]
taupiqueur has joined #river
alexherbo2 has joined #river
vaivis has quit [Read error: Connection reset by peer]
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
Guest99 has joined #river
Guest99 has quit [Client Quit]
Guest74 has joined #river
waleee has quit [Ping timeout: 248 seconds]
waleee has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
<Guest74>
Hello, I am currently working with the river-status-unstable-v1 and am encountering an issue: the "layout_name" event seems to be erroneously generated whenever I click the mouse or switch views/tags. Am I missing something? Thanks!
Guest74 has quit [Quit: Client closed]
Guest74 has joined #river
Guest74 has quit [Client Quit]
Guest74 has joined #river
<ifreund>
Guest74: ah, yeah should probably not do that
<ifreund>
it's not a bug but it's also just plain inefficient and easy to fix
<ifreund>
Guest74: fixed
Gozenka has joined #river
<Guest74>
Thanks so much! I'll test it right now
Gozenka has quit [Client Quit]
Guest74 has quit [Quit: Client closed]
Guest74 has joined #river
Gozenka has joined #river
<Gozenka>
riverctl map normal Ctrl+Alt BackSpace exit
<Gozenka>
error: invalid modifier 'Ctrl'
<Gozenka>
using "Ctrl" as modiffier works in some other mappings, is there something wrong with this declaration?
<Guest74>
ifreund: It works like a charm! However now it seems the event is not generated if there are no views in the current tag
<ifreund>
Gozenka: uh, I don't think Ctrl works with any mappings, Control is what I see in the man page and code
<ifreund>
I wouldn't be terribly opposed to adding Ctrl as well, but I'm pretty sure that's never been supported
<ifreund>
Guest74: hmm, to get a layout name when there are no views we would have to send a request to the layout generator with no views to lay out which seems kinda weird
<ifreund>
(the layout name comes from the layout generator)
<ifreund>
I'm not sure if we ever specified it in the protocol, but rivertile currently asserts that river doesn't send a layout demand with 0 views
<ifreund>
Which means that changing that behavior would likely break many people's layout generators, I think it's not worth it
alexherbo2 has quit [Remote host closed the connection]
<Gozenka>
aha sorry, it seems I was glancing over the comments in example init that denote Ctrl, while actual commands use Control
<Gozenka>
# Super+Ctrl+[1-9] to toggle focus of tag [0-8]
<ifreund>
that's confusing, we should fix that
<ifreund>
fixed
<Guest74>
Hmm, but that means if the user changes the layout on an empty tag, my bar cannot update the layout text until they add a view, even though it is applied internally