<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]