_whitelogger has joined #river
whitequark has left #river [#river]
travankor has joined #river
_whitelogger has joined #river
leon-p has joined #river
leon-p has quit [Quit: Lost terminal]
_whitelogger has joined #river
ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/2020-12-24
ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
leon-p has joined #river
ifreund has quit [Quit: WeeChat 3.0]
ifreund has joined #river
leon-p has quit [Quit: Lost terminal]
leon-p has joined #river
travankor has quit [Ping timeout: 240 seconds]
snakedye has joined #river
<snakedye> i've been working on some layouts recently recently and they work for the most part except when I increase the "mod-master-count". The master window disappears from the layout when it's not 1.
<snakedye> There's also "The amount of views dedicated as master" I found confusing. Right now I use it to define the master window and it seems to work ex. rivertab 5 4 0.5 1920 1080 will return the layout of the master window for the 4th one.
<snakedye> basically I have an issue with "mod-master-count" making my master disappear and I suspect it's due to the way I use the second argument
<leon-p> When you set "mod-master-count" to n, you do not set the n-th window as master, but rather the first n windows.
<leon-p> at least that's the intention
<leon-p> in reality the master amount and master factors can be safely ignored ore interpreted in any way you want. They are nothing more than recommendations
<leon-p> when your windows disappear, then your layout is faulty
<leon-p> it is pretty easy t accidentally move windows off the screen
<leon-p> snakedye: took the liberty and snooped your github account to looke through your layout. Your interpretation of mod-master-count is a bit unusual, but should work just fine (although it panics if master count is 0, which you probably want to fix).
<leon-p> Manually executing it with test values gives window dimensions that look fine, but you are right, when used in river the window disappears. Something is a bit off.
<leon-p> I'll see if I can find whats wrong.
snakedye has quit [Ping timeout: 245 seconds]
snakedye has joined #river
<leon-p> snakedye: I think I found your problem
<leon-p> got confused by it a bit as well
<leon-p> but mod-master-count does not set the master count, it modifies it.
<leon-p> so when you do "mod-master-count n", you increase master-count by n.
<leon-p> (use negative n to decrease)
<leon-p> and when the master count is higher than the view amount, your layout puts all windows to the right side.
<snakedye> yes I also noticed another error
<snakedye> when the master-count is < 1 the master just isn't displayed
<snakedye> it skips it
<leon-p> that is expected: when the master count is 0, there are simply no master windows
<leon-p> you may want to clamp the master-count value inside your layout: 0 < master-count <= window-amount. That should fix all issues you are having.
<snakedye> thanks, it solved it on all my layouts
<leon-p> btw, expect your layouts to break in the future. Just a heads-up.
<snakedye> yes I saw that PR
<snakedye> will river layouts be scrapped entirely?
<leon-p> Nope, custom layouts is still the way to go.
<leon-p> however they will work differently
<snakedye> how?
<leon-p> instead of programs being called everytime a layout is needed, they'll be always-running wayland clients which receive an event when a layout is needed.
<leon-p> solves a few issues and clients will receive more information about present windows as well
<snakedye> okay that's pretty neat
<snakedye> does that mean the layout can be ajusted depending on the focused windows?
<leon-p> No, because layout clients have no idea what window is focused and won't receive an event when focus changes
<leon-p> however they can know what windows are currently displays (title + app-id)
<leon-p> s/displays/displayed
<leon-p> As an example, you could have a layout that acts differently if Firefox or your editor is currently visible on an output
<snakedye> so you could firefox to always be master
<leon-p> no
<leon-p> because layout clients can just move windows around on the screen. They can not control their position in the list
<leon-p> it's a pretty hefty limitation, but you can't solve that trivially.
<leon-p> so at their core, layouts will remain what they are now. Anything more and we'd move into window manager terretory, where complexity sky-rockets
<snakedye> with the way layouts work now, if I also had an ordered list of windows, I could display the window at Firefox's index where I would usually put the master without caring about the master-count
<leon-p> nothing will change in that regard. You can place windows where ever you want and can ignore the master count (which really is just a recommendation).
<leon-p> you could trivially port your current layout
<leon-p> I don't yet have a rust eample layout client, but the C one is fairly simple.
<leon-p> the rust version probably wont be much different
<leon-p> as you can see, simple (content-un-aware) layouts can just be ported by replacing the logic inside handle_layout_request()
<snakedye> thank you that was very informative
snakedye has quit [Remote host closed the connection]
<ifreund_> We could make a layout client that runs layout generators as they currently exist for some kind of backwards compatibility
snakedye has joined #river
leon-p has quit [Quit: leaving]
snakedye has quit [Remote host closed the connection]