<Guest78>
hello, is it possible to have manual tiling like sway in river?
TheAnachron has joined #river
traidare2 has quit [Read error: Connection reset by peer]
traidare has joined #river
traidare has quit [Remote host closed the connection]
traidare has joined #river
stevenn has joined #river
eShaev9z has joined #river
eShaev9z_ has quit [Ping timeout: 260 seconds]
<leon-p>
Guest78: layouts are always automatic / list based. you can have an arbitrary amount of variables influencing the layout, but it does not allow manual per-window adjustments
<leon-p>
if you prefer the way sway tiles, you probably should just use sway
<Guest78>
I wanted to try River because of scriptable config and sway seems a bit bloated but it is good
<Guest78>
I mean the configuration part
<leon-p>
calling sway bloated is a bit silly. if you take the minimalism thing too far, it eventually becomes a joke
<leon-p>
Guest78: yes, that is a common pattern
<Guest78>
I gues you could influence the variables influencing the layout using a keycombination ?
<Guest78>
in this way it could emulate manual tiling?
<leon-p>
no
stevenn has quit [Quit: Quit]
<NickH>
LOL I was just looking at my init file and thinking that I have to much stuff hard coded, and that it really should be reading most of it from a config file :-D
<NickH>
s/to/too
<dagle>
NickH: And then that config file should read from another config file?
<dagle>
And it's config files all the way down.
<NickH>
dagle: LOL
<NickH>
And now I'm looking for a toml parser for bash...
uncomfy has quit [Remote host closed the connection]
waleee has joined #river
traidare has joined #river
<ifreund>
Just pushed the Zig 0.11.0 patch to master, sorry for the conflicts
<ifreund>
gotta unblock myself working on fixing mpv
<leon-p>
ifreund: do we keep the cursor image to the view? IMO that's one of the big reasons why resizing and moving views in river feels better than in other desktops so it would be a shame to lose that
<leon-p>
although we could also free the pointer and insead just render a detached cursor immage at the view to simulate the effect
<leon-p>
s/image to the view/image attached to the view/
<ifreund>
leon-p: the latter is what we do already really
<leon-p>
I faintly remember implementing both, didn't rememer what I went with :)
<ifreund>
the part that overcomplicates stuff is trying to stop clients from ever being partially offscreen for clients that have their own opinons about what size the should be (like mpv)
<ifreund>
if mpv commits a buffer bigger than river asks for while it is already at the edge of the screen handling that without letting it just render offscreen becomes quite tricky
<ifreund>
it's arguably a protocol error for mpv to do that, but nobody seems to enforce it or really care
<leon-p>
well, that originally comes from me not wanting to implement render a view on multiple outputs simultaneously, but with the scene graph that should be trivial no? And while I do prefer the UI design paradigm that forbids this, we could technically drop that restriction now
<leon-p>
although we may need code that enforces such restrictions later, should the window management protocol allow resizing layouts via pointer
elshize has quit [Ping timeout: 255 seconds]
waleee has quit [Ping timeout: 272 seconds]
<ifreund>
leon-p: yeah, rendering a view across outputs is trivial now. If we were to allow dragging floating views between outputs we would have to at some point move them from the view stack of one output to the other though
<ifreund>
and I actually quite like the UX of views being bounded by the edges of the output for arranging windows
<ifreund>
not that I use floating views regularly at all...
<ifreund>
maybe we should just switch to the more common UX of letting windows be moved past the edges of outputs but locking the cursor to the edge of the output layout
<leon-p>
that has a few problems as it allows views to "get lost" beyond the edges
<ifreund>
not if you can't move the mouse off the edge
<ifreund>
I think I prefer the status quo though and plan on sticking to it with some exception for weird clients that commit buffers larger than what we asked for
<leon-p>
👍
<leon-p>
we could also crop buffers that are too large
<ifreund>
Yeah, though not easily until we update wlroots
<JustineSmithies>
Sorry so just grab the tarball ? A prebuilt binary is that what you mean or do i build Zig from source ?
<JustineSmithies>
Ah yes I see what you mean and thank you.
<novakane>
yep, personally I have multiple version and then symlink to my $PATH with the name I want, usually just "zig" for the current version
<JustineSmithies>
So ln -s /usr/bin/zig /path/to/zig-binary is that correct ?
<JustineSmithies>
got it thanks
JustineSmithies has quit [Quit: WeeChat 4.1.0]
JustineSmithies has joined #river
<JustineSmithies>
Success I got the latest River built from the master with Zig 0.11.0 on Void. Thank you novakane ;)
<novakane>
np :)
elshize has joined #river
TheAnachron has joined #river
Guest87 has joined #river
waleee has joined #river
elshize has quit [Ping timeout: 255 seconds]
TheAnachron has quit [Quit: TheAnachron]
<k-man>
does river have some way i can emulate alt+tab from other non tiling window managers?
<ifreund>
k-man: what exactly do you want it to do?
hamarukan has joined #river
hamarukan has left #river [#river]
JustineSmithies has quit [Quit: WeeChat 4.1.0]
<k-man>
ifreund: toggle between recently used windows? i'm not exactly sure how I want to present that in river but i find i miss that from stacking wm
<ifreund>
k-man: perhaps you're looking for focus-previous-tags?