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/
kotto has quit [Quit: WeeChat 4.0.2]
haliucinas has quit [Read error: Connection reset by peer]
haliucinas has joined #river
eShaev9z has quit [Ping timeout: 246 seconds]
eShaev9z has joined #river
angry_vincent has joined #river
leopoldek has quit [Ping timeout: 246 seconds]
tiosgz has joined #river
<tiosgz> NickH: indeed i did, over on codeberg https://codeberg.org/river/river/pulls/4
<NickH> tiosgz: great. This bug bit me again today about an hour after my question to you.
<tiosgz> ahh :/
<NickH> What is the pathway for PRs from codeberg.org to end up at github.com/riverwm/river ?
<tiosgz> i also patched wlr-randr to work around it / always trigger it, but that's useless by now
<tiosgz> 'as usual' - they get reviewed, merged locally on if's machine and pushed to all three remotes (gh, cb, srht) iiuc
<NickH> Somewhat off topic, but codeberg related, I just migrated my gitea instance to forgejo today :-)
<tiosgz> cool :)
<NickH> Ok, good to hear it is realtively straight forward.
<tiosgz> if it weren't, my contributions could've been cut off :P
<tiosgz> but thankfully we got good and open people here
<tiosgz> (not that i'd contribute much, but... it can be annoying for gh-only projects)
<tiosgz> everyone: i wonder if in the end, adding a focused-index indicator to the layout protocol would be better than not doing so
<tiosgz> i should note, however, that i don't know its bloating/debloating history
taupiqueur has joined #river
<leon-p> tiosgz: when I worked on the initial layout stuff, I decided against making the layout generator aware of the focused view
<leon-p> here is why:
<leon-p> originally, layout generators had no protocol and there were no layout commands
<leon-p> they were just one-shot executables river ran when needed, with a few hardcoded paramters (main size, etc.) as command args
<tiosgz> generally & for all my use cases i agree that layout should be unaware. i was just thinking if it's stronger than the use cases like yesterday's (just saying till you finish your explanation)
<leon-p> giving them the index of the focused view would have given them a parameter which would not cause a new layout on change, which seemed a bit weird
<leon-p> I guess you can do a layout demand on every focus change, but that might be a bit much
<leon-p> also index wouldn't really work anyway
<leon-p> because if you spawn new views / close current ones, the index will refer to a different window, which probably doesn't lead to desired behaviour
<leon-p> maybe we should not have removed the advertise_view event from the protocol, but oh well
<leon-p> either way, I don't expect any non-trivial changes to the layout protocol to happen anymore
<tiosgz> agreed to the last one :D
<tiosgz> still trying to understand how you mean the thing with spawning/closing views
<leon-p> you can read up all the old PRs and issues if you want a bit more of my and isaacs reasoning for things. can't guarantee I agree with all my old takes anymore though
<tiosgz> like, ofc it will refer to a different view, but is there a moment where it wouldn't be the focused one?
<leon-p> tiosgz: you are refering to the person wanting to implement cfacts, right?
<tiosgz> yeah
<leon-p> because in that case, yes it would make it possible to write some system that allows changing the size of the focused view
<leon-p> however:
<leon-p> those size changes are bound to the position in the view stack, not to the specific view
<leon-p> which from what I can tell isn't what cfacts is doing and IMO not exactly great UX
<tiosgz> oopsie, i thought cfacts just gave focused view more space. but at least it seemed to be the goal in this case
<tiosgz> tis cool how much one can learn from suggesting a random change
<tiosgz> thanks!
<tiosgz> (not that i'd go suggest random changes just to learn more stuff haha)
<leon-p> FWIW I tried layouts that depend on the focused window back in 2020 (I think?) when I was still toying around with my own compositor
<leon-p> fealt really /really/ awkward and I scrapped it immediately
<tiosgz> tis just different people liking different stuff ig. why do we have various layouts after all
<leon-p> 🤷
<leon-p> we don't actually have that many different layouts, I think
<tiosgz> with stacktile there's quite a lot
<tiosgz> not that it'd be comparable to dwm or awesome, but still
<tiosgz> (and i meant it generally, including these two wms)
<leon-p> at least all dwm layouts can be ported to river. I'd actually argue river layouts are a super-set of dwm layouts, since river supports arbitrary layout parameters
<tiosgz> i wouldn't argue that it really depends on how and what everything you count
<tiosgz> but i've never used dwm, for the record
kotto has joined #river
kotto has quit [Client Quit]
ayushnix has quit [Remote host closed the connection]
<Guest52> I'm still here :)
<Guest52> In regards to indices of views, that was just me trying to work with the information that I had. A unique ID would obviously be preferable, as I certainly don't want to retain the size of a window after it closes (i.e. the view that takes it place should not inherit its bounds).
<Guest52> The whole thing about focus was kind of a red herring anyway. The more general problem is "how can I discriminate views"?
<Guest52> ...which from what I understood isn't possible at the moment
leopoldek has joined #river
tiosgz has quit [Quit: tiosgz]
groknull has joined #river
groknull has quit [Remote host closed the connection]
Ordoviz has joined #river
taupiqueur has quit [Quit: WeeChat 4.0.2]
waleee has joined #river
ayushnix has joined #river
ayushnix has joined #river
ayushnix has quit [Changing host]
ayushnix has quit [Remote host closed the connection]
ayushnix has joined #river
ayushnix has quit [Changing host]
ayushnix has joined #river
waleee has quit [Ping timeout: 260 seconds]
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]
Guest97 has joined #river
Guest97 has quit [Client Quit]
Guest52 has quit [Quit: Client closed]
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]
jjjjj has left #river [bye]
Guest68 has joined #river
Guest68 has quit [Client Quit]
Axenntio has joined #river
Axenntio has quit [Client Quit]
waleee has joined #river
ayushnix has quit [Remote host closed the connection]
Szadek has quit [Quit: off]
Szadek has joined #river
Ordoviz has quit [Quit: WeeChat 4.0.2]
Axenntio has joined #river
Axenntio has quit [Quit: Axenntio]
angry_vincent has quit [Remote host closed the connection]
Axenntio has joined #river
Axenntio has quit [Quit: Axenntio]
waleee has quit [Ping timeout: 244 seconds]
waleee has joined #river
leopoldek has quit [Ping timeout: 260 seconds]